Controlling Software Projects: Management, Measurement, and Estimates [Facsimile] [Paperback]

T. DeMarco (Author)

Product Details

• Paperback: 296 pages
• Publisher: Prentice Hall; 1 edition (June 14, 1986)
• Language: English
• ISBN-10: 0131717111
• ISBN-13: 978-0131717114
• Product Dimensions: 9.8 x 7.1 x 0.6 inches
• Shipping Weight: 1.5 pounds (View shipping rates and policies)
• Average Customer Review: 4.2 out of 5 stars  See all reviews (4 customer reviews)
• Amazon Best Sellers Rank: #705,630 in Books (See Top 100 in Books)

More About the Author

Discover books, learn about writers, read author blogs, and more.

Customer Reviews

Most Helpful Customer Reviews

9 of 11 people found the following review helpful:

5.0 out of 5 stars A must read for any software manager, April 6, 2001

By 

"[e-mail]" (Seattle, WA USA) - See all my reviews

This review is from: Controlling Software Projects: Management, Measurement, and Estimates (Paperback)

"You can't control what you can't measure", is how DeMarco opens this seminal work in software project management, and the primary focus of this book is how to develop an effective strategy for measuring software development costs and thus build a reliable means of estimating the cost of future projects. Most of this discussion is, in my opinion, too dated to be of direct use (DeMarco suggests, for example, that counting the now obsolete metric "frequency of compiles" as an indicator of software stability). But the true genius of this work lies in the periphery of his discussion--particularly insightful comments into what not to do when managing software development. Useful insights, lucid prose, and DeMarco's engaging wit keeps this book on the top of the stack on my desk, and I expect to revisit it often.

5 of 6 people found the following review helpful:

4.0 out of 5 stars A Classic, but is it timeless?, August 23, 2005

By 

David Bock "javaguy" (Hamilton, VA USA) - See all my reviews
(REAL NAME)   

Amazon Verified Purchase

This review is from: Controlling Software Projects: Management, Measurement, and Estimates (Paperback)

Tom Demarco should be required reading for anyone who is a software engineering manager. This book was one of the first in a long line of references for quantifying the craft of software engineering.

But this book has not aged as well as, say "Mythical Man Month" or "Death March". Don't get me wrong - I am giving it 4 stars because it is still full of excellent material; you just need other, more 'modern' references to help give this book perspective. With the proper perspective, this book really helps explain "The more things change, the more they stay the same", something that is often forgotten in this fast moving field.

The context that this book needs today is that of a given 'methodology', whether that be Extreme Programming, Scrum, Unified Process, or CMMi. If you don't have a model in mind, I would start with the book "Agile Software Development, Principles, Patterns, and Practices", by Robert Martin.

1 of 1 people found the following review helpful:

4.0 out of 5 stars Still viable but showing its age, September 11, 2010

By 

Erik Gfesser (Lombard, IL United States) - See all my reviews
(VINE VOICE)    (REAL NAME)   

Amazon Verified Purchase

This review is from: Controlling Software Projects: Management, Measurement, and Estimates (Paperback)

This text was initially noted by this reviewer while reading a white paper written by Johanna Rothman that a colleague recently passed on to me entitled "Are We There Yet?: Creating Project Dashboards to Display Progress", and after a good experience reading "Waltzing with Bears: Managing Risk on Software Projects" by Tom DeMarco and Timothy Lister (see my review) this reviewer was ready to re-experience the superb writing style and diagram notation of the author. But then the publish date was discovered. Is it possible that a 30-year-old project management text can be appreciated in an age of agile development? In the opinion of this reviewer, large portions of this book are still viable, but the reader needs to maneuver through some of the information that is outdated, and in many cases downright risky to follow. Because of this intermingling, this reviewer can only recommend this text to readers with a substantive amount of software development experience.

While following a reading of this book this reviewer still recommends "Software Estimation: Demystifying the Black Art" by Steve McConnell (see my review) as the best overall project estimation text, what is appealing to this Six Sigma practitioner are the metrics presented throughout this text even though McConnell indicates that many of the early metrics that are still being referenced within the industry were harvested from large government projects. Metrics can be compelling, but it helps to understand that there are many different types of software development projects taking place in many different corporate cultures, and "Balancing Agility and Discipline: A Guide for the Perplexed" by Barry Boehm and Richard Turner (see my review) interestingly enough co-written by the individual who wrote the forward for the object of this review 20 years prior can greatly aid leadership in this industry as they choose which direction to take in this regard.

While the content in this book is well connected throughout, DeMarco discusses four main areas that are each dedicated a section in the book, although the largest amount of text is dedicated to the second section: (1) "Chaos and Order in the Software Development Process", (2) "System Models and System Metrics", (3) Cost Models, and (4) Software Quality. Some of the questions that DeMarco addresses might be posed as follows: What does it mean "to control" a software development project? What is estimation and how can it be approached effectively? How can project costs be projected into the future? How are metrics generated and who should do this work? What long-term benefits can be provided by a cost model? What exactly does software quality mean and how can related goals be achieved? The author also provides four appendixes, but in the opinion of this reviewer only the third, entitled "A Tailored Primer on Statistics", is suggested reading.

While less than 300-pages, this book covers a lot of ground. While the author carefully lays out his approach on how to gather metrics in the second part of the book, it is obvious from a year-2010 perspective that this method relies much too heavily on the classic Waterfall software development methodology, and so this part of the book should only be given a cursory reading. Some of the material in this section is beneficial, but harvesting this information is like separating the wheat from the chaff. In other words, while still taking into account the excellent conversational writing style of the author, the reader is advised to read other material such as that found in texts sited earlier in this review. Because DeMarco offers so many great diagrams in this book, a possible way to explore this third section is by looking at these diagrams to determine whether reading the surrounding text is worthwhile. The fourth section on quality does not seem to belong in this book, even if it were not for its lack of inclusion within the subtitle. The other two sections were well received by this reviewer, especially the first.

At the outset, DeMarco is entertaining by presenting the default definition of "estimate", which he writes is "the most optimistic prediction that has a non-zero probability of coming true", and his proposed definition of "estimate", which is "a prediction that is equally likely to be above or below the actual result". In addition, the author exposes one chief villain of accurate estimates: corporate policies that use estimates to create incentives. As the author explains, "when such a policy is allowed to prevail, the estimation process is nothing more than a charade. Whenever estimates are required, the person requiring them is not truly interested in the estimator's probabilistic assessment of when the work will be done or at what cost. Rather, the 'estimator' is being asked to establish goals for performance. In many cases, it's even worse: The 'estimator' is being asked to accept previously established goals. And what shall the characteristics of those goals be? If they're going to serve real prods for the development process, they have to be totally unachievable."

If you do not have time to sit down with this book for long periods, this reviewer recommends that the latter portion of chapter four where the author discusses five objections to empirical software projection be read at a minimum: (1) "We don't have the data. Without that vaunted bluebook, the metal extrusion estimator would be nowhere. That's where we are." (2) "Even if we have the data, we haven't got anything to correlate it with. What can we use as the early measurable indication of size? (If you say lines of code, I'll scream.)" (3) "Each software system is different. You can't use data about developing small on-line systems in PL/I with experienced people to project results for a development of large batch systems in assembler by novices." (4) "The data don't converge. The tolerances will be so wide that no one will accept the results." (5) "Upper managers won't accept the projected numbers because the figures will be too high. The worker bees won't work as hard without unreasonable numbers to strive toward. Everybody's ego will be offended by the idea that the work is predictably doable and that people's efforts are interchangeable."

As this reviewer wrote the list in that last paragraph, he was reminded of some of the technologies mentioned by Frederick P. Brooks, Jr. in his classic work entitled "The Mythical Man-Month" (see my review). "PL/I"? "Batch systems"? "Assembler"? As this reviewer mentioned in his earlier review of "Object-Oriented Technology: A Manager's Guide" by David A. Taylor, "the next language of the day/week/month/year" will come and go soon enough.