Software Project Survival Guide


For many people here, writing software is, if not a job, then a hobby. Our enthusiasm is a double-edged sword. Our technical knowledge is usually much greater than people who just develop software for a living. This sounds like a big advantage, but it’s not as large as you would have thought.

Let’s have a look in ‘Software Project Survival Guide’ (SPSG) to see what Steve McConnell, famed author of ‘Code Complete’ and ‘Rapid Development,’ has to say on the subject.

The most relevant bit I can find is in chapter two. It’s a project survival test. Out of thirty-three questions, only one (28: “Does the project team have all the technical expertise needed to complete the project?”) is directly related to our ability to effectively code.

That can’t be right, can it?


While you’re still reeling over the consequences of that last paragraph, I’ll slip in some of the dull things that the book has to cover and finish with some of the more glamorous stuff at the end when you’re brain is back in gear.

Some of the most important stuff is ‘management.’ Whether it’s planning, quality assurance, tracking what’s been developed so far or checking on the number of defects, it’s not the ‘techies’ that are the most important.

At first this comes as a shock, but the more you think about it, the more it makes sense. Unless you know what’s going wrong, you can’t fix it. Unless the complete design is documented a team can’t effectively write the software quickly.

Think about Linux kernel development. It obviously work well, but it’s not terribly optimal. The same bug might get fixed several times and there’s not a huge amount of up to date documentation so people have to dive in at the code. For free software this works fine — since the time is usually free, but if you have deadlines and are under contract to deliver a working product on time you’re going to lose a lot of money.

Good bits

McConnell takes the three hundred pages to explain these past two paragraphs in detail. It sounds very dull, but he has a clear, friendly style that makes it, if not entertaining, then not as dull as it might have been.

He splits the project into stages, explains in broad terms what they are and documents each one in more detail in the later chapters. It’s all very clear and logical leaving you in no doubt what stage you’re currently at and what you should be doing for the successful execution of it.

Bad bits

‘Code Complete’ is a book that just about everyone that writes computer programs should read. ‘Software Project Survival Guide’ does not fall into the same category. The book should be read by “anyone who has a stake in a software project’s outcome” according to the preface, but that is only accurate once you define the type of project it covers.

To cut a long story short, if you write software professionally you should read it. It’s probably more use to managers and team leaders, but you can be a better developer if you know the kind of things that need to be done. Besides, almost everyone will be in charge of people at one point and will need a broader picture than merely what the other modules do. (Well where I work that’s true, anyway.)

It covers projects that have a customer whether that’s an internal customer, an external client or people that buy shrink-wrapped software. What it doesn’t cover are software projects like Linux, massive sprawling projects developed because someone is interested in doing it. This is not unreasonable. Half the challenge in a ‘normal’ project is tracking whether you’re running to schedule. If you don’t have a schedule and cost target it doesn’t matter. However, maybe we could take a few hints from the book to ‘streamline’ the process.


Steve McConnell has done it again. I don’t think that it will go down as a classic like ‘Code Complete,’ but SPSG is an indispensable book for any developer that has any interest in the process and not just lines of code.

The facts

Author: Steve McConnell

Cost: ?22.49

ISBN: 1-57231-621-7

Buy this book from of from