Communications of the ACM

One of the most popular and successful approaches to estimating software projects is the Putnam model. Developed in the 1970s by Larry Putnam, Sr., this model shares with other models a reciprocal exponent relationship of effort/cost to development time.

CACM Administrator

The following letter was published in the Letters to the Editor in the August 2011 CACM (http://cacm.acm.org/magazines/2011/8/114929).
--CACM Administrator

I commend Phillip G. Armour's Viewpoint "Practical Application of Theoretical Estimation" (June 2011), as I'm always on the lookout for ideas concerning software estimation, even as I ponder my own eternal mantra: "Estimates are always wrong."

I agree with Armour but think he missed an opportunity in his section labeled "Practicing the Theory" to emphasize how agile methods avoid the extremes of compression and relaxation. Relaxation is avoided by breaking traditionally slow-to-deliver projects into small agile pieces, each easily delivered within the related market window. Working with these pieces also serves to avoid compression, since the same number of people can deliver the smaller agile pieces more quickly.

Armour also did say this is all theoretical and that even under the guise of agility companies regularly try to ramp up too many agile pieces too quickly.

Geoffrey A. Lowney
Issaquah WA

Phillip Armour

Geoffrey, you are entirely correct. Estimates are always "wrong." In fact I have a bit of an allergic reaction to the phrase "accurate estimate" and I've pointed out in my column that it's a straightforward oxymoron. Estimates are neither accurate nor correct, but they can be *useful*

A "good" estimate (and there's an article that describes exactly what that is) informs the decision-making process *at the time of estimating* and provides a more optimal solution than would have been chosen without doing the estimate.

You're also right about Agile. The careful workflow management that goes with good Agile practices greatly improves the prediction and control of resources. But estimation in Agile is more about workflow management than it is about macro resource allocation. It's hard to scale up true Agile to very large complex coordinated systems. But then. of course, it's hard to build very large complex coordinated systems no matter what you use.

Just recently I was able to use the (very good) Story Points metrics obtained on quite a large project to calibrate an entire organization in a most useful way. It also showed that this company's regression away from Agile and back to a massive and monolithic paper-based process was costing the company a lot of money. That's a useful estimation activity.

Thanks for the feedback