Estimates and Productivity

This blog post by Bruce Eckel has a number of fascinating points, particularly regarding estimation:

[In Waltzing with Bears,] DeMarco and Lister first point out something very important. When someone asks you how long a particular subproject will take, it's usually implicit, and sometimes explicit, that they want to know the shortest, most optimistic time for this task. DeMarco and Lister note that the actual time for finishing a task is a probability curve, and if you only ever give the shortest time, you are giving the leading edge of the curve, where it touches the axis. Thus, each subtask prediction has a 0% probability of being correct. This means your project completion time estimation starts out, from day one, with a 0% probability of being correct. They suggest a relatively simple change in behavior: give, instead, the middle of your probability curve for each subtask, so you begin with a palpable completion time. It doesn't make the completion time predictable, but it does make it significantly less wrong.

Should we all start giving our estimates as probability curves?  It's an interesting idea.  I think estimates are probably hard and time-consuming enough as it is; thinking of them as probabilities, while useful, might not yield much practical benefit.  And using the middle of the curve sounds nice, but I wonder if it's just adding layers of imprecision to an already imprecise guess.  If we're already bad at guessing the start of the curve, will we be any better at guessing the middle?

The post goes on to discuss a fascinating study about estimates:

In Peopleware, DeMarco and Lister also look at estimation, but for its effect on productivity. They run a test where managers and programmers estimate the completion of a project, in various combinations: the manager alone, the programmer and manager together, the programmer alone, and no estimate at all. The rather striking result was that the programmer was most productive when there was no estimate at all. So not only are we estimating very badly, the cost of estimation itself appears to be quite significant. Of course, current business thinking will look at these issues and say "very interesting, but we must have estimates and naturally we want the most optimistic ones."

This last point seems rather condescending towards "business thinking."   I think it's important to dwell on the issue a bit.  Of course folks on the business side want estimates -- how else could they possibly run their businesses?  Not only do you need estimates for scheduling and timelines, but -- far more importantly -- you need them to figure out the cost of a project so you can decide whether to do it at all.

And isn't it natural to want optimistic estimates?  Isn't part of what we're paid for to mitigate risk by avoiding potential pitfalls?

Maybe instead of trying to mold our estimates to fit into our software development practices, we have to mold our software development practices to produce accurate estimates.  It sounds like a nice idea; if only we knew how to do it.

But I don't want to get too far away from the earth-shattering conclusion of the study: "The rather striking result was that the programmer was most productive when there was no estimate at all."  What could possibly explain that?  It certainly seems to contradict the Hawthorne Effect.  The blog post goes on to discuss pay-for-performance (discussed next) and suggests that this entire way of thinking is demeaning.

Unfortunately, this leaves us mired in an awful situation: we need estimates to function, but our programmers are most productive if they don't give estimates.