New Book Review: "Controlling Software Projects"

New book review for Controlling Software Projects: Management, Measurement & Estimation, by Tom DeMarco, Yourdon Press, 1982, reposted here:

 

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.