Sign In

Communications of the ACM

The business of software

Practical Application of Theoretical Estimation


View as: Print Mobile App ACM Digital Library In the Digital Edition Share: Send by email Share on reddit Share on StumbleUpon Share on Hacker News Share on Tweeter Share on Facebook
3-D geometric pattern

Credit: Tiemen Rapati

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.

The full text of this article is premium content


Comments


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


Displaying all 2 comments

Log in to Read the Full Article

Sign In

Sign in using your ACM Web Account username and password to access premium content if you are an ACM member, Communications subscriber or Digital Library subscriber.

Need Access?

Please select one of the options below for access to premium content and features.

Create a Web Account

If you are already an ACM member, Communications subscriber, or Digital Library subscriber, please set up a web account to access premium content on this site.

Join the ACM

Become a member to take full advantage of ACM's outstanding computing information resources, networking opportunities, and other benefits.
  

Subscribe to Communications of the ACM Magazine

Get full access to 50+ years of CACM content and receive the print version of the magazine monthly.

Purchase the Article

Non-members can purchase this article or a copy of the magazine in which it appears.