Estimating Software Projects

There is an interesting article called “Software Estimates and the Parable of the Cave“. It starts out well. The cave parable is effective and clearly conveys the problem with estimating software work. However, there is a big section of the article called “Applying this Wisdom” which I think does a dis-service to everyone. Let’s look at this closely…

“Draw on your experience.” Okay, didn’t we just get through a parable that said that experience was inapplicable, or at best questionable? Okay, let’s take that as a given. So what can we do? Don’t estimate. Seriously.

“Expect the unexpected!” I love this one. This is like saying tell me what you don’t know that you don’t know! Or please tell me the price (on Dec. 20th, 2009) of the shares of the 20th (after today) startup to go public on the NASDAQ. The future is unpredictable. The farther out, the worse it is. So what can we do? Don’t estimate.

“Provide estimates that are ranges…” I’m not sure why anyone would want an estimate that is a range. Are you going to give me a money-back guarantee that you will deliver at the end of the range? Are you saying that if I through all the money and resources and intelligence at you you will be able to deliver at the low end of your range? Are you saying that you don’t know? So what can we do…(wait for it!)? … Don’t estimate.

“Make your estimates as fine-grained as possible”. Let’s take this one to the limit shall we? The finest grained estimate we can make is based on complete knowledge of every single tiny task needed in order to create the software… which is logically equivalent to writing the software and then telling me how long it actually took. Yes, this is getting a bit repetitive… so what can we do… (let’s hear it from the audience!!!). Don’t estimate.

“Use incremental and iterative processes”. Okay, I admit, I _like_ this one. But how does it relate to estimates exactly? Not exactly clear, but I suppose I have to admit, I have a way to do this in mind… if you must. (But it has absolutely nothing to do with what is recommended in “applying the wisdom” above. Oh… and Don’t estimate.

“Work on the riskiest part of the system first”. Jeez Louise! Let’s pretend I’m running a business. I tell you: “here’s all the stuff I need and want”. You tell me: “this part ‘A’ is the riskiest, I’m going to work on that first.” I say, “screw you! I want the most important thing first!” And you say…. what exactly? (Well, if the most important is also the riskiest, then actually I say “okay”.) And what does this have to do with estimating?

“Environment of trust.” I like this one too. But I don’t think it has anything to do with estimation except as a surface symptom (failure to meet estimates should _not_ lead to more work trying to get better at estimating). I think it has to do with truthfulness, quality and a few other things beyond the scope of this article…

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

2 thoughts on “Estimating Software Projects

  1. Hi Mishkin,

    I guess I struck a nerve, with this blog. Let me try to address some of your points. First, doing estimates isn’t even optional. Estimates and schedules are what separates software as a business from software as a hobby. Any product that is sold must be planned and coordinated with other business functions like marketing and sales. So, we need to do the best estimates we can to be responsible business partners.

    Beyond that, estimates are part of the look ahead process. In order to do an estimate that is anything but a guess, requirements must be understood and some level of design must be performed. These steps are essential in building effective software. The decompositions built as estimates can also serve as important checklists to make sure we haven’t missed important steps like unit testing and to make sure we know when it’s time to make a decision and move on.

    So, we obviously disagree on the importance of estimates. I’d like to address some of the other points as well:

    “Draw on your experience” The point is that few things are imperically new. Human intelligence allows us to learn by analogy and apply lessons learned from one thing to things that are similar. Even though we can’t build perfect estimates, we can use our experience to do the best we can.

    “Expect the unexpected.” This does not say, “Know what unexpected things will happen.” I am simply stating that you should know that there will be things you cannot foresee. If your schedule only includes the things you can think of, then you will almost certainly run over.

    “Provide estimates in ranges” This is one of the key methods for deailing with uncertainty and allowing your manager or the business team to play “what if” scenarios. You seem to take the perspective that because estimates are uncertain that they are not worth doing. Again, this is not an option in the business world. They are called “estimates” instead of “predictions” because we know there is uncertainty.

    “Make your estimates as fine-grained as possible” Here you seem to be taking “as possible” to an illogical extreme. The point of my paragraph is that estimates for shorter, simpler tasks are more likely to be accurate than for longer, more complex tasks. “As possible” should perhaps be read as “as possible with the knowledge you have at that moment”.

    “Use incremental and iterative processes” This relates to estimates by helping us to address uncertainty. This is equivalent to running into the cave for a preliminary exploration in the parable. With incremental and iterative approaches, the more you accomplish the more you will know about what is left to do. In traditional waterfall models, early steps or phases shed no light on later ones.

    “Work on the riskiest part of the system first” Wow! I really touched a nerve here. Perhaps the unstated assumption is that we’re building everything that is planned. So this isn’t a method for deciding what to build and what not to build, but what to build first within a single delivery cycle. Too often developers tackle the easy or fun things first, saving the difficult or unknown areas for later. Then, when they hit this part they gain the insight that shows that this whole thing needs to be redesigned or even respec’ed. By tackling these parts first we waste less time before coming to that conclusion.

    “Environment of trust” I disagree. I think this is at the heart of effective estimates. In places I have worked where this trust did not exist, the development team would routinely inflate estimates because they expected the business team to arbitrarily cut the development schedule. When this trust exists, the business team and development team cooperate on a plan that is the best assessment of what we can accomplish in the time that is available. Certainly it also has to do with “truthfullness, quality and {many} other things beyond the scope of this article…”

    I hope this helps a bit. Of course, we may always differ on whether estimates are useful, but maybe this clarifies some of my points for you.

    –Scott

  2. A nice subject to debate, and for me, working as a consultant, and always towards clients directly, it could almost be seen as the core of my business; the better the estimates, the better business and also ease to plan my own work. But I think the debate suffers as I think either of you don’t look at it from the consultant’s view, only from an “Internal Development Department” view, i.e. reporting to a manager. When working towards clients directly it is essential that you are able to produce good estimates, especially if you are working with a fixed price! Therefore I think the view on how developers and managers handle the estimates, described in ScottW’s The Perfect Estimate: “You’ve probably heard that when making estimates you should take your best guess and double it. It’s also common knowledge that standard practice for many managers is to cut all estimates in half.”.

    Well if I, as a consultant, always would double my estimates, I surely would not win any bids, and if I (or my manager, if I had one) would cut this in half, we would probably lose money (since I still need to work double as much as told, given that the estimate is at least kind of correct) and we would probably make our client pissed of since we’re not being able to deliver what we have promised on time.

    Some additional comments:
    “Draw on your experience”. Well, I guess this is kind of pseudo… don’t you always draw on your experience when doing something? Rather, it is more or less impossible to do anything without using your experience, and if you still would try to do it, what could you benefit by doing so? It’s just stupid…

    “Expect the unexpected!”. I think i get ScottW’s idea, i.e. including a risk factor(?), but those words imply exactly what Mishkin stated. Meaning that you probably would need to add so much time (and cost) due to risks, that you don’t get the deal at all.

    “Provide estimates in ranges”. Well, at least for me, this is an internal measure which never can be communicated to the clients; it is rather a way of dealing with uncertainty and have a way of solving problems if (or more likely, when) they arise. But they are never (or seldom) presented to an external client.

    “Work on the riskiest part of the system first”. I agree a bit with both of you here, though, I would not actually “work” on the riskiest part, but rather prototype or “spike” a solution for it, as an activity when estimating. And further on, when presenting the estimate for the client, he may even change his priority on the sub tasks when he realizes that some task takes too long time to much to perform.

    ScottW says “…we may always differ on whether estimates are useful”. We probably do, depending on which context you’re in. To me, they are almost the most important part of my work… but not the most fun stuff to do for a tech nerd ;-)

    /Ricky

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>