4

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.

Alex Punnen
  • 239
  • 1
  • 7
  • 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 09: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 – Alex Punnen Mar 11 '16 at 09: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? – Michael Borgwardt Mar 11 '16 at 09: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 09: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. – Michael Borgwardt Mar 11 '16 at 10:11
  • @MichaelBorgwardt That is hardware. We are talking about software here. – Euphoric Mar 11 '16 at 11:36
  • @Euphoric It's not _only_ hardware. It's not like the iPhone didn't need any software development, or all of its functions are implemented only in hardware. – Iker Mar 11 '16 at 12:18
  • @Iker But software development can (and will) continue even past the "finished" date. So the argument that "had to up to production and distribution" doesn't hold water. – Euphoric Mar 11 '16 at 12:42
  • @Euphoric It will, up to a point. At some point, the SW has to be delivered to the factory to have a 1st install in the phone. Some parts (esp. the updating mechanisms) have to be pretty good quality by then, even if you're taking into account you can update it after selling it (unlike most of the embedded systems) – Iker Mar 11 '16 at 16:02

5 Answers5

4

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.

MichelHenrich
  • 6,225
  • 1
  • 27
  • 29
Michael Borgwardt
  • 51,037
  • 13
  • 124
  • 176
  • 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 09:05
  • 1
    estimate is an estimate, inaccurate is plain misleading – Alex Punnen Mar 11 '16 at 09:45
  • @Euphoric: if you disagree with that statement, then you fail at basic logic and there is no point in further discussion. – Michael Borgwardt Mar 11 '16 at 09:46
  • @MichaelBorgwardt I'm disagreeing with premise that in absence of deadline, project would go until dawn of time. With proper management, business people see capabilities of project in it's current state and can decide when to stop it if they are satisfied by it. – Euphoric Mar 11 '16 at 09:55
  • 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. – Michael Borgwardt Mar 11 '16 at 10:04
  • You are saying that it is logical to decide about doing a project from estimates, that are known to be off by order of magnitude? You are saying that allocating resources up-front makes sense when you don't even know what tasks need to be completed? It seems the illogical one here is you. – Euphoric Mar 11 '16 at 11:35
  • 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
  • 1
    @Euphoric, that is a form of estimation – Chris Beck Mar 11 '16 at 12:42
  • 1
    @ChrisBeck No. Estimation means you try to infer from past data how long something take. It is not estimation when you already have finished product. – Euphoric Mar 11 '16 at 12:43
  • @Euphoric: Start small and see if it works, then extrapolate based on how long the small project took, to how much the large project will take... is also a form of estimation. And since no one will care about the small project, only the large project, you do lose resources if the experiment fails. You lose whatever time / pay you put into it if you decide to cancel the project. – Chris Beck Mar 11 '16 at 12:45
  • @Euphoric - how does a manager know what a smaller project is? Or indeed, how long the developers are going to take on it before it's written off? When the manager checks up a week later and the developers haven't finished the small project, and the manager meant "a day at most" when they said small, whose fault is it? – Hecksa Mar 11 '16 at 12:46
  • 1
    @ChrisBeck That is not what I mean. There is no extrapolation of time from the small project. You just decide if you wan to continue or not. NOT how long the whole thing is going to take. – Euphoric Mar 11 '16 at 12:49
  • @Euphoric: Okay... but whether or not you want to continue depends on how long you think the whole thing is going to take. Unavoidably. – Chris Beck Mar 11 '16 at 12:50
  • @Hecksa You define scope, not time. You pick project features so that it is "smallest viable product". – Euphoric Mar 11 '16 at 12:50
  • @ChrisBeck Never saw manager who decides how long something is going to take. It is always "how much money it makes compared to how is invested." – Euphoric Mar 11 '16 at 12:51
  • @Euphoric - and developer time is one of the units which management require to figure out how much money they are investing. – Hecksa Mar 11 '16 at 12:54
  • @Euphoric, also, time to market is important. You make a lot less money if you release with last-year's features. There is a saying, "Time is Money". – Chris Beck Mar 11 '16 at 12:55
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.

Philipp
  • 23,166
  • 6
  • 61
  • 67
  • 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. – Michael Borgwardt 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. – Alex Punnen Mar 14 '16 at 00: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. – Alex Punnen Mar 14 '16 at 00:46
0

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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
0

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

Cone of Uncertainty

Wikipedia link "Cone of Uncertainty"

Bradley Thomas
  • 5,090
  • 6
  • 17
  • 26
0

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.

pietromenna
  • 1,148
  • 5
  • 10