I cringe ever time I see or hear a mention of software estimation. After years of seeing my estimates and the estimates of my colleagues fail, I’ve come to the conclusion that beyond the roughest of figures software estimation is impossible. This is not due to negligence or incompetence. Nor is it due to an immaturity of the software field. It is simply a fact of software development that software estimation is a myth.

The Right Metaphor

To defeat the estimation myth, we must first discard the faulty metaphors assigned to software: construction, writing, engineering. In reality, developing software is more akin to a developing human relationship.

When I was in grad school I began to notice that from time to time a particular young woman would join my table at the cafeteria for lunch. I didn’t think much about it until one day I looked up at her and realized that perhaps the reason she was sitting at my table was because she liked me.

We geeks aren’t known for our social intuition so this was a big moment. So I did some rough calculations on the speed and complexity of relationship building and making proper adjustments for personality factors I estimated we’d be married in 18 months . . . not!

A marriage “go live” date was the last thing on my mind. In fact it was months and several relational millstones later before we even discussed a date. As it turned out, circumstances beyond our control delayed even that date. But, in the end the pieces fell together and we were happily married. Now we have a house, a mortgage and two small children.

If we substitute “software project” for “young woman” and “maintenance and support” for “mortgage and family responsibilities” we would have the perfect description of the software development project.

Relationships Are Unpredictable

Why can’t we predict relationships? It is certainly is not due to insufficient study. People have strived to understand how love works for thousands of years. Yet, at best matchmaking has always been an art of intuition and guesswork. There are simply too many variables and too many unknowns to predict how two humans will relate. The same is true of software. Each new project is built in unknown territory. Even a simple project has a myriad of variables and unknown factors. It is simply impossible to predict the result.

An Example

A few months ago a web service I’d written began to eat up memory like crazy. I’d coded it using a modern garbage controlled language so theoretically a memory leak was impossible. But, it was happening. I tracked down every obvious choice. I talked to my co-workers. No luck. Finally, after two weeks I finally discovered the problem–a small bug inside a loop was interacting with Microsoft Active Directory to create hundreds of AD tokens. Another bug caused these tokens to skip garbage collection. Schedule? Throw that to the wind.

Every software developer has stories like this one. You probably have one from just last month, or even last week! The interaction between human and computer is simply too complex to predict when the next brick wall will come sailing out of nowhere. I like to tell junior developers that the art of developing software is like running hurdles—except that instead of hurdles we run at brick walls and in the middle of the night. When we hit one we scramble up, dig beneath, or bash our way through then sprint headlong into the next wall.

Large Project Estimation

Individual estimation is impossible. However, if enough developers are involved the random occurrence of schedule breaking events averages out and becomes a measurable “white noise”. The “white noise” can be then factored into the estimate as overhead. Estimation models such as COCOMO are built on this predictability.

However, there are clear limitations to this type of model.

A limited number of critical path options may narrow a project schedule to a tiny set of dependencies. Once a schedule is dependent on a very small group (or individual) developer(s) the project schedule can (and will!) be blown about by random chance.

If a project depends on unproven technologies or technology unproven to the domain the number of random roadblock events increases unpredictably. A key assumption of large project estimation is that the average number of schedule delaying events per developer is known and can be factored in as an overhead. With new technologies this can not be known and can not be accurately factored into the estimation.

Range of Precision: Models are appealing because they provide a number—however, even in ideal conditions they are far from precise.

In short, I would be extremely cautions to schedule or budget based solely on the results of a software estimation model. However, these models are useful and should be carefully considered in the light of the limitations above. One of the best uses may in fact be as an antidote to unrealistic optimism–I.e. “No, this isn’t a 6 month project. It really WILL take *THREE FULL YEARS!*”

Summary

We (and our users) must accept that a software estimate is about as good as a prediction of marriage on the first date.

Upcoming Article: How to keep your “customer’s” happy without estimates. (Coming in Early September)

Further Reading:

Large Limits to Software Estimation

Share this: Twitter

Facebook

Like this: Like Loading... Related