A metaphor that every manager who comes near software should read

[jducoeur]

Bob, one of my co-workers, just forwarded me this article on "Why are software development task estimations regularly off by a factor of 2 or 3?" It's an extended but delightfully on-target metaphor, matching the reality of programming in almost every detail.

If you are involved with software in any way, and don't understand what this metaphor is talking about, I encourage you to sit down with your programmer friends -- most can explain in graphic detail (complete with war stories) why it is so right...

Comments

[goldsquare.livejournal.com]

Honestly, the real problem is this...

So, for our next trip, we're going to walk north to Six Rivers National Forest. Now: we know that we can walk 4 miles an hour for 10 hours a day....

Tom DeMarco, in a lecture entitled "PeopleWare Revisited" had a really great slide, that asked the key questions: "We do QA on the software. Why don't we do QA on the software schedule?"

[jducoeur]

A rather delightful way of looking at it...

[umbran.livejournal.com]

I wish I had this article two weeks ago, when I was trying to make exactly this point (in different words) when suggesting an adjustment to our estimation process.

As the person who is typically on the Other side of the equation

[crosslet.livejournal.com]

I'm pretty sure the author was only trying to highlight the problem and its a nice analogy. How do we address the problem so we can provide realistic estimates? The reality is most of us are working for a paycheck. To continue getting paid, we need to deliver code that we can sell. In large enterprise software, the sales cycle can easily be 6+ months. Missing delivery by a 2X to 3X typically has significant time line and cost implications.

Re: As the person who is typically on the Other side of the equation

[jducoeur]

Oh, absolutely. (Remember, not only am I writing enterprise software, I am writing it for large banks. I am altogether too aware of the hell of the long sales cycle.) But the crux of his point is right on-target: that we tend to be much too blithe in the process of estimation, seeing only the high-level view and failing to recognize that the details are what cause schedule failure.

Of course, his story doesn't involve his friends telling him that they really *need* him to get to LA by next Sunday, and encouraging him to not sweat the details too much before he commits. Sadly, the real world usually involves that as well...

Re: As the person who is typically on the Other side of the equation

[crschmidt.livejournal.com]

I was hoping that I would get to the end and find some pointer to "Here is how you should deal with this", or "A guide to telling your manager that San Francisco is not a 10 day walk from LA."

Overall, with careful practice, I've gotten very good at estimates of my own work. (It took years of writing down an estimate for everything I did, and then reviewing whether I hit in the end or not.) Our team is also relatively good at estimates of our work. Unfortunately, we work within a larger group where estimation is not just not done well, it's often not done at all -- or done to exactly the same level as this analogy starts with.

What's the path to improve the situation?

Re: As the person who is typically on the Other side of the equation

[jducoeur]

I don't think that there's any simple silver bullet for this problem, so the article was probably wise to avoid suggesting one.

The only approach I've ever found to work adequately is velocity-based estimation, within the context of a generally Agile-style environment. That is:

-- Every project is thought of as a story stack, decomposed to at least a moderate granularity before you start.

-- The team does abstract point-based estimates of those stories. These are just guesses, but they're consistent guesses by the same people.

-- You track how long it actually takes to get things done, coming up with a rough metrics of points/month for the team.

-- Once you've done that once or twice, you now have the velocity multiplier (that points/month value), so subsequent projects can use that number to come up with a vaguely-accurate estimate. Keep refining that on a regular basis.

None of this is easy, though: it requires a lot of discipline from *everyone* involved (management at least as much as engineering), it takes a good deal of time to bootstrap, and it doesn't trivially port across teams unless you make a company-wide effort to develop a consensus understanding of how to estimate points. It can be done, but you're talking a minimum of six months (and more likely a couple of years) to really get it humming.

(Memento started doing Agile in a really serious way just about a year ago, after a year or two of me forcing it for my project. True to the usual predictions, we're just about now at the point where it's working smoothly and starting to produce consistent metrics...)

[calygrey.livejournal.com]

Murphy is smiling.

[jducoeur]

The thing is, I don't even see this as Murphy's Law stuff. When I think about Murphy, I think about unforeseeable (or at least, unforeseen and not stupidly) problems. But this is describing the all-too-typical situation in software development, where the problems *are* somewhat foreseeable, at least from a statistical viewpoint, but everyone glosses over them in the belief that *this* project will just go perfectly...

[sibilla-dangers.livejournal.com]

this actually works for the architecture world extremely well... possibly any project management that involves design of some sort...

it sounds like the vast majority of what my days are like....

[cvirtue.livejournal.com]

Off topic: I love your hat.