Why are we anyway doing Software Estimation knowing it is broken?

Question

This is one SW development problem that hits the sea of developers as they crash into the rocks of management. Somewhere down the line the estimate given by the programmer gets translated to a date and quite soon it translates into a deadline. Against this ticking bomb, efficiency can be increased, quite often quality gets sacrificed. A cursory googling threw up notorious amounts of links and studies and sarcasms (read Dilbert) on the deviation of estimates. I have a feeling that some companies have given this up already.As a programmer I find it very difficult to give an estimate without doing a prototype; Loved the quote from Jørgensen and Grimsta in Wikipedia

 It's easy to estimate what you know.
 It's hard to estimate what you know you don't know. (known unknowns) 
 It's very hard to estimate things that you don't know you don't know. (unknown unknowns)

Know when there are multiple SW modules involved in product development, it is almost impossible to have a good estimate that will deliver good quality. If all the studies are also pointing to the same thing, I am wondering is it not time to throw this process out from SW development.

Answer 1

Even a very inaccurate estimate is still better than none.

Not doing any estimation at all would be basically saying to management "whatever you want programmed, I have no idea, it could take years and cost billions", which in business terms means "no programming should be done".

The correct way to deal with inaccuracy in estimation is to allow for it and update your plans whenever you get new information after development has started - as a project progresses, estimates for the remaining work will become more accurate over time.

Answer 2

Removing deadlines from the development process is not a solution, because exact deadlines are a business need.

A software project is more than just the development part. Marketing, sales, system administration, support, user training etc. all need a fixed release date so they can plan their part of the project accordingly. Of course it would be better from a pure development perspective to just say "it's finished when it's finished" and not release until all features work to specification and all bugs are squished. But you can't plan a project on that basis. You must have a schedule so you can coordinate properly between the other project participants, or they will start to become inefficient and the project will fail because they don't have the capacities when you need them.

So the true solution to the problem is not to try to invent a process which doesn't have deadlines. The true solution is to optimize our time estimation methods so we can find more realistic deadlines and to change our development processes so we notice it early when a deadline can not be fulfilled. There are quite a lot of approaches to this and so far we haven't found the one which works best - but we are still trying.

Answer 3

Estimation have several purposes. One is "when can this project be finished", but at least as important is estimation as a tool for decision and resource allocation.

Say you boss decides response times in a web app should be improved and someone suggest rewriting the app in C++ as an option. Just jumping into the C++ port without any estimates would be a disaster. A simple off-the-cuff estimate of cost versus benefit will have great business value as it could be compared to other potential improvement like implementing output caching. In this case even a wildly imprecise estimate is a lot better than no estimation.

No doubt estimates are hard, but they also get a worse reputation due to problems that have nothing to do with estimation itself.

First, you should not conflate estimation and scheduling. Estimates are estimating the amount of time needed to solve a task. Turning an estimate into dates is a question of scheduling, and this may be affected by outside conditions. For example a developer might be assigned to spend some of his time on another project, and that will obviously affect the schedule though the estimate is the same. A project schedule will obviously slip if the project manager forgets to include holidays, people getting the flu etc. into the schedule, but that does not mean the estimate was bad.

Also, scope changes during development will affect the schedule. Scope change is a natural occurrence as you learn more (although uncontrolled scope creep is dangerous), but obviously estimates will need to be updated if the scope changes, since now you are doing a different project than the one you estimated. Again, that does not mean that the original estimate was bad or useless.

Furthermore you should be aware that the amount of work put into the estimation process will affect the quality of the result. There is a big difference between an off-the-cuff estimate and a detailed estimate with the full requirements spec broken down into function points and sub-task specified to the granularity of a few hours. Obviously the the more work the better estimate, but that is in itself a cost/benefit decision.

Answer 4

See "Cone of Uncertainty", a useful concept which has helped me more than once.

Wikipedia link "Cone of Uncertainty"

Answer 5

Software is not only "Development", includes pre-sales, sales, and management and many others.

Generally speaking, estimates are used to put prices or cost to Softwate Projects (be it costs with resourse allocation, or the price to charge to an external company).

When it is only cost, it is also to know about the resource allocation, how many days we needs X person. How many days we need somebody with Y profile, etc.

When it is price, it is all about profit margin and mitigating risks.

When it is non of those, maybe it is just a date to make an announcement. Business needs that some dates to be set as deadlines.

To close, the main issue with estimates is when they are not treated as what they are. They are basically our expectations on what will be achieved. And Expectation should also be described with a uncertainty, for example, I believe developing functionality X, assuming that Y and Z are true, maybe with a 20 % of certainty.