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.

  • Because managers want to feel they are in control. And most simple and obvious way is to ask for how long a work will take.
    – Euphoric
    Mar 11 '16 at 9:03
  • 1
    The way I see it is not the how part; but the why part; Nobody announced when Chrome would be released, when iPhone will be released, or damn when anything good that I am using is released Mar 11 '16 at 9:08
  • @AlexPunnen: That they weren't announced in advance publically doesn't mean there were no internal project plans based on estimates; you can be 100% certain that there were. The iPhone was presented on the Macworld conference - you really think it was a coincidence that it was ready in time for that? Mar 11 '16 at 9:52
  • 1
    @MichaelBorgwardt Presented or finished? Those are two different things. Many projects are "presentable" way before they are finished.
    – Euphoric
    Mar 11 '16 at 9:53
  • @Euphoric: sales started about half a year after that presentation - and half a year is not much time at all to ramp up production and distribution at that scale. Mar 11 '16 at 10:11

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.

  • 2
    Not doing any estimation at all would be basically saying... I disagree. As long as there is trust between developers and management, and developers are periodically showing results of their work, then development without estimates can work just as good, or even better, if management is trying to manage using completely wrong estimates.
    – Euphoric
    Mar 11 '16 at 9:05
  • 1
    estimate is an estimate, inaccurate is plain misleading Mar 11 '16 at 9:45
  • 8
    @Euphoric: I'm not talking about deadlines, I'm talking about deciding whether a project makes sense economically and should be started at all. Yes, it's idiotic to set hard deadlines for feature-complete delivery based on estimates done before development starts, but that's not the only way you can use estimates. You use them to allocate resources, to make plans with the understanding that they might have to change, and you use updated estimates to know when and how to change the plans. Mar 11 '16 at 10:04
  • 3
    @Euphoric: Try to take management's point of view. If they are going to spend investor money to achieve a goal, they need to have some idea what the potential risk and potential reward is. Even if it's just "ballpark" estimate. If you say "it is impossible to estimate at all", that means it is so risky that something else should be done with the capital. It's not about trust between management and engineers, that the engineers won't slack off -- management needs to know, even assuming the engineers do their part, is it worthwhile to spend company resources this way?
    – Chris Beck
    Mar 11 '16 at 12:27
  • 1
    @ChrisBeck There is an alternative. Instead of deciding if huge project is worth the resources, start small. Make small project and see if it works. If it does, you can continue to improve it, if it doesn't then you loose the resources, but it shouldn't be much. There is no need for estimation. Are you saying that this option is inferior to one where you try to guesstimate how much WHOLE project costs and decide if it is profitable or not, while knowing there is big chance the real cost will be way over what would be profitable? Assuming it is actually finished?
    – Euphoric
    Mar 11 '16 at 12:40

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.

  • 1
    Even from a pure development perspective, "it's finished when it's finished" can be a toxic attitude, as evidenced by Duke Nukem Forever. Mar 11 '16 at 13:47
  • 1
    @MichaelBorgwardt On the other hand, Blizzard Entertainment was quite successful with that doctrine. I would assume that's because they have a better project planning and controlling process to prevent feature creep from causing the project progression to go backwards.
    – Philipp
    Mar 11 '16 at 13:50
  • Well I started programming, I used to prototype the core of the projects to give pretty accurate estimates. But my module was part of the whole system. Then I saw that unless the product is really mature, that is three or more years in the field, no initially announced deadline was ever met. Marketing sales, technical support all were involved in these projects. This was a pretty process oriented German company. Later the truth began to hit me, unless I uncover all the unknowns my estimates will be plain wrong; and it is hard to do when you start handling more. Mar 14 '16 at 0:42
  • The same I saw repeated in a different company that took us over.This time, much worse. Deadlines for huge projects slips by years. Techniques like Story point etc initially looked good.But when the 'business need' forced us to started converting these to numbers, it lost its effectiveness. The best we could estimate was complexity, and no number to this. I guess new produces are created like this. This practice just hurts. It is time to throw estimates out; like what was mentioned in answer, just estimate of complexity without any time involved. Mar 14 '16 at 0:46

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.


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

Cone of Uncertainty

Wikipedia link "Cone of Uncertainty"


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.