I bought this book as a result of a favorable review on Slashdot. I should have known better. Perhaps if you are right out of college this book might have a few good tips, but those are buried in cliched prose and observations of the obvious. Here is just one example:

One of the all-time classics, the crusty and cranky coder is a timeless symbol found in trade magazine advertisements everywhere. Far from fiction, these are very real people. With a diminished patience for others sculpted from many years of corporate ineptitude, these folks tend to be irritable, frustrated, and they just basically want to be left alone. Or else. They may or may not appear to have any teeth, but it's wise not to antagonize them. This is particularly good advice for the young. They may seem powerless to affect your life, but tick them off and you're liable to find out exactly how they've managed to survive in the business world for so long.

Along with the "crusty coder" we find "suits" (those would be managers and marketing types) and, of course, our heroic software engineers, who are just artists that want to be left alone to develop beautiful, high quality software. Instead they find themselves bogged down in deathmarch schedules on software projects with constantly expanding feature lists.

While there is some truth in this picture of the life of the software engineer, it is so obscured by cliche and stereotypes that it is of little value. An underlying theme of the book is that programmers are oblivious "propeller heads". With their heads in the clouds of object hierarchy, programmers rely on the author to point out that those who pay for software development expect a return on their investment.

The author never mentions a core fact in the life of most software engineers: they don't do development. Although most of the literature concentrates on designing and implementing new software, in most cases programmers fix bugs in and extend existing code. The really ugly truth is that many programmers spend most of their time fixing huge masses of undocumented, poorly designed code that was written by engineers who have long since departed the company.

The book seems to be heavily slanted toward large corporate IT software development. It is copyrighted in 2002. It does not mention that the programmers in large corporate

IT departments, where you might really find examples of the empty "suits" described in this book, are disappearing, as programming jobs are exported to India, Russian and China.

When it comes to Silicon Valley, the book is much less accurate. The management of companies like H-P may be populated by professional managers, but it is increasingly rare to find managers who do not understand the technology or the software development process. Even IBM is producing interesting and innovative software these days. Good managers are like good anything else: they are rare. But the portrait of idiot managers in this book is right out of a Dilbert cartoon. Yeah, they exist, but in the current savage technology environment they are an endangered species.

The founders of start-up companies don't have a simplistic 30,000 foot view of technology. They know the technology, even if they are not implementing it. In most cases the they are very bright people.

This book has a section on the importance of quality assurance (QA) departments and the author denounces software that is shipped without testing (who can argue with that). But what he totally misses is that even when they exist, QA departments are ineffective. QA should be part of the development process, not some separate department populated by lower status engineers. The QA people should work closely with the developers, not as some separate department, sending the message that quality and testing is not something that developers worry about.

The author is, apparently, a software consultant. He writes that there are always jobs around. I suspect that as he was writing the book, the world was changing around him. For most people, software consulting has dried up. In fact, in the current environment, you're lucky to have any job that pays a decent salary in software development. While in the past you could leave a situation you did not like, this is no longer true.

Some writers can use a casual writing style to express real ideas and good observations. This book uses a casual writing style to express empty ideas and the obvious. Save your money and buy Steve Maguire's excellent book "Debugging the Development Process" instead. Maguire's book has real content, is easy to read and has some solid useful advice.

Ian Kaplan
August 2003
Last updated on:

Book review table of contents

back to home page