Applied Software Project Management
Andrew Stellman and Jennifer Greene
O'Reilly & Associates, 2005
308 pp., $39.95
Software Project Secrets: Why Software Projects Fail
165 pp., $39.99
At my partner's request, I finally uninstalled Homeworld (still the best game ever). That left me with lots of time to catch up on my reading, so I plowed through Stellman and Greene's Applied Software Project Management and Stepanek's Why Software Projects Fail back to back. They made an interesting pair, and the differences between their authors' positions say a lot about where the software industry is today.
Stellman and Greene's book is the more conventional of the two. Their aim is to put everything you need to know to run a small-to-medium-sized software project between two covers. After a short introduction, which lays out the principles they believe successful managers should follow, the book is divided into two parts. The first, "Tools and Techniques," includes all the usual suspects: planning, estimation, schedules, reviews, requirements, design and programming, and testing. While their language is sometimes a little highfalutin' ("Wideband Delphi estimates," anyone?), the advice is all solidly grounded and eminently practical. It's all been said before, but as covers go, this is as good as The Clash's version of "I Fought the Law."
The book's second half is about the act of management. Its chapter titles tell the story: "Understanding Change," "Management and Leadership," "Managing an Outsourced Project," and "Process Improvement." In my experience, these topics are nearly impossible to teach in book form: The only way to learn them is to have someone coach you while you're doing them. That said, Stellman and Greene do as good a job as anyone, while thankfully avoiding anything that smells of Tony Robbins. It's a solid book, well researched, and definitely worth reading.
Stepanek's Software Project Secrets is a marked contrast. The tag line on the front cover is, "Resolving the conflicts between software development and project management," and it's clear from page one that the author (a) has been caught in this particular vise more than once, and (b) really wants to find a better way to do things. Drawing on both his personal experience and the published literature, Stepanek gives 12 reasons why software is different. Some of them are inarguable: Software is complex and abstract, and construction is design.
But then there's: "Requirements are incomplete." Stepanek treats this as being intrinsic to software development, when in fact, it is merely common (bad) practice. His own point number 11, "Change is considered easy," is the reason, but shifting sands are no more inescapable in software than they are in civil engineering. "What happens if the scope can't be completely defined?" he asks, as if it were any easier or more natural for architects to get specs from their clients than it is for programmers.
Similarly, while Stepanek refers to many of the classic works in software engineering, he seems to have missed most of what's appeared in the primary literature in the last 10 years. New journals such as Empirical Software Engineering have both reflected, and encouraged, new studies of what actually works and doesn'tstudies that are methodologically sounder than many of their predecessorsand I think they ought to be required reading for anyone writing about software engineering today. I share Stepanek's sense of frustration, but think that software engineering isn't as special as it is often convenient for software engineers to believe.
Amazon.com Recent Top 5 Programming Books