Software Estimation Is a Losing Game (2014)

A more appropriate question is not, does software estimation help improve project management, but is project management a suitable model for software?

I am a proponent of the idea software is a new form of literacy. We generally do not project manage the next paragrpH or the next chapter. writers are often faced with deadlines, but rarely have to justify themselves on a daily basis.

Improving estimation will just result in slightly better inputs to a process that at best hinders us and sucks creativity and joy.

Creativity and joy are fantastic qualities that are difficult to quantify on an accountant's spreadsheet. Clients have to be able to budget sufficiently for project work, and the only way they can do that is with an estimate. This is how business is done. "Uh..we'll send you a bill when we're done for...like...whatever it costs. I guess?" Isn't going to go over well when responding to a potential clients RFP.

Software time/cost estimates are essential. If I run a business, I need to have some understanding if an investment will have a return. If I have no way to gauge that at all, then there are many more predictable endeavours where I can spend the money and realize a return. When you invest, do you simply say the future is unknowable and bet on raw emotion? I should hope not. That's not to say you may err in your judgment of available facts, you may still lose, but at least you understand some of the parameters about what constitutes success.

Software time/cost estimates are exactly that: estimates not guarantees. We tend to think of such things in terms of project management and contract enforcement. If anything, that is where we go wrong. What we should do is not try to understand the whole project in terms of an unalterable roadmap, but rather as a guideline for managing expectation and for informing decisions that are made during the course of a project. I use my estimates to sell the project, yes, but I also tell the client that as we go along we will be making many decisions that will move us away from our initial plan as we better understand both the issues and opportunities a project affords. Sometimes spending more time than planned will make sense, sometimes it won't and we cut the feature. Sometimes we find that we have failed to identify important features and sometimes we identified a feature early on that isn't as important as we thought. The overall project plan and estimate does set a benchmark to ensure the economics are still correct, after all if we lose that we lose the point of the project entirely, but we don't turn that plan into dogma. We don't lose sight of the reason that caused the project to exist.

So, yes, we need estimates no matter how hard they are to get accurate. What we need to stop doing is equating that estimate as an oath to be upheld regardless of what new knowledge comes along.

I can estimate some tasks very accurately. I know that adding this new flag to my system will take a day.

Other tasks I can accurately say I don't know how long they'll take. This new feature is... a couple of weeks? This new application is... a few months? I can roughly guess (estimate!) but there's a wide certainty margin.

That uncertainty is never built into the mathematical model used by project managers, which is invariably a simple addition of scalar estimates. The only common way of dealing with uncertainty is to pad the estimates (multiply by two, etc), but that's still not a statistical boundary -- it's just a scalar.

Furthermore, when adding uncertain values, they wind up not being independent, for a number of reasons -- the lessons from one feature are carried on to the next, or the next task is easier because of new existing code, or because as you approach the original deadline you invariably throw out feature requirements. So you can't necessarily just add all the uncertainty values.

So a better approach to estimation would be to formulate a (simple) model which encodes each estimate as {guess, uncertainty, independence} and then provides a function for compounding the guesses and uncertainty and independence factors in a realistic way.

Thanks. Yeah, there's a fairly large number of formal management techniques, but like you said, they're very rarely used.

PERT: https://en.wikipedia.org/wiki/Program_evaluation_and_review_...

Barry Boehm's recent work:

http://www.amazon.com/Incremental-Commitment-Spiral-Model-Pr...