Two Books on Software Project Management
I read these two books on project management back to back: at my partner’s request, I finally uninstalled Homeworld—which is still the best game ever—and that left me with lots of time to catch up on my reading. They made an interesting pair, and the differences between their authors’ positions says 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 twelve reasons why software is different. Some of them are inarguable: software is complex and abstract, and construction is design.
But then there’s #3: “Requirements are incomplete”. Stepanek treats this as being intrinsic to software development, when in fact it is merely common (bad) practice. His own point #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 ten years. New journals like Empirical Software Engineering have both reflected, and encouraged, new studies of what actually works and doesn’t—studies that are methodologically sounder than many of their predecessors—and 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.
Andrew Stellman and Jennifer Geene: Applied Software Project Management. O’Reilly, 2005, 0596009488, 308 pages.
George Stepanek: Software Project Secrets: Why Software Projects Fail. Apress, 2005, 1590595505, 165 pages.