Some time ago, I ranted joyously about Steve McConnell’s legendary tome Code Complete (the second edition). I received a copy of his “Software Project Survival Guide” in the same bundle with Code Complete, but only just now got around to reading it. (That 35 minute walk on the treadmill every morning is great for this — I’m wired from my morning espresso, and I have over half-an-hour of mind-numbingly boring walking time to kill. Topics that would knock me out in the evening — such as software project management — are much more interesting in this context.)
I know that he is a teensy, geeky-looking software engineer, but I will readily admit that I love Steve McConnell. The man is both a scientist and a realist, which is probably what makes him a fantastic engineer. If he had chosen something like physics or molecular biology as his discipline, his publication record would probably be even more staggering than it is now.
This book is no-nonsense. There’s a lot to take from it, but in my opinion, the three most valuable contributions of this book are:
(a) Unlike most agile planning and management books, it deals directly with teams that are fairly large (upwards of 20 developers). The agile answer is usually “That’s too big. Make smaller teams.” I’m not saying that the agile approach is bad, but it’s refreshing to see discussion of the issue in a different light here.
(b) The checklists of all the stuff you need to prepare for a release. I’ve been on teams where this hurt us badly, because you just don’t want to admit to yourselves that all this “extra stuff” is going to take a significant amount of time. McConnell says it perfectly: He notes that when you itemize things like this, some people object and say “The project is going to take us forever if we plan to do all of these things.” His response is that it will take even longer if you don’t plan to do them, because you’re going to end up doing them all one way or another.
(c) He provides a number of strategies for gathering project data, and a handful of metrics (and more importantly, references to many other metrics) that you can use to compute size, scheduling, and cost estimates. I’ve become really interested in estimation and planning recently, after reading another book on the subject (this one from an agile camp — review forthcoming), and also after observing the astonishing estimation features present in FogBugz, the flagship product of yet another software icon’s company (Joel Spolsky’s Fog Creek Software).
The book is admittedly quite dry in parts. For this reason, I recommend that you read it while on the treadmill. (Ha ha.) It’s not quite as bad as that software engineering textbook I blogged about a few months ago, but some of the chapters come close. Also, while I imagine the techniques described in this book are still quite relevant today, it is starting to suffer from age. Notably absent is any reference to agile methods, because the agile manifesto and its associated marketing machine hadn’t been assembled yet. I actually found this refreshing, because it gets tiresome to see how every single other methodology out there has to somehow relate itself to or distinguish itself from agile methods. Also, it’s interesting to see how some of McConnell’s suggestions actually fall squarely into the agile manifesto. For instance, he warns that developers should always have significant input into project estimates. He also emphasizes that you should split your production release into short iterations, and deliver production-quality software at the end of every iteration to keep overall quality high throughout the span of the project. His overall approach has more structure and requires more up-front planning than agile methods do, though.
I also liked how he dealt squarely with the issue of making a good preliminary estimate for the purposes of budgeting, so that the people in charge can make a rational decision about whether to go ahead with the project or not before anyone has started writing any software.
Even if you’re going to use a looser methodology than the one that McConnell describes in this book, it’s worth having around as a reference simply for the checklists. There is a ton of supporting material that goes into a software product, and it’s really nice to have an itemized list of these products at hand right from the beginning so that you don’t forget anything.
Now I have to get my hands on the rest of his books!
Comments (0)