I finally figured out something that I might want to actually write about – process. By process, I mean the software development process and its related parts. I realized the other day that I see a lot of nonsense or badly applied good ideas, and I feel like I should say something about it. So hopefully I will take my ideas, my “truths” about software development and if nothing else inspire you to respond with a long rant yourself.
My first target – estimating. In particular, one graphic that shows up regarding estimates over and over and over again that I think is just downright wrong. You’ve assuredly seen the familiar “funnel” that people use to describe the process by which “good” estimating occurs. Early on, at Estimate #1, there might be a margin of error of plus or minus 4 times. So, if you estimated something would cost $100, it might cost as much as $400 or as little as $25. You just don’t know because you have very basic software requirements at this point.
Now don’t get me wrong, I agree with the idea of an estimate having both a high and low range and that it gets more accurate as you know more. It’s the graphic itself that bothers me. Here’s why…
When someone estimates and knows more, the next estimate is bound to go up or down. It isn’t going to stay at $100 most likely. Specifically, I’m bothered by the worst case scenario. Let’s say we make our first estimate of $100. At worst, it could be $400. We learn more by the time we get to the next estimate and therefore we estimate now at the high end of our prior estimate – we estimate $400. Ok, ouch! Our estimate just rose 4x what we told the customer at our last estimate point. But it is going to get worse! If we continue this trend, that $400 would turn into $800 and so on…
By the time it’s all over, we’re at an estimate of $1200 – and if the worst case plays out, our final cost will be $1500! 15 times what we originally told the customer. Sad thing is, I’ve seen projects that do exactly this.
Now I will accept there is another way to interpret the funnel. Let’s say that when you make your first estimate that it in fact defines the correct upper boundary. That is, if you estimate $100, it will never exceed $400. So the worst case path we could follow would cap the upper limit always at $400. It would look like this:
Now I’ll agree that this isn’t as bad as my prior scenario, but essentially what happens is that you slowly converge on the maximum defined by the original estimate. This is still a very unhappy customer – a final estimate that is 3.6 times what you originally told the customer. No wonder managers get mad at software developers! This funnel we all see isn’t helping anyone’s expectations of what a series of ever-refined estimates is going to really do.
Do I have an answer? No, but maybe in a subsequent rant I’ll come up with one. For now, I think you can save yourself a lot of trouble by either a) getting a lot better at doing early estimates or b) not giving an estimate until you know enough to give a good one.
