Programmer Musings

Review of Software Exorcism

Software Exorcism
Bill Blunden
Apress, 2003

I was really looking forward to this book, having spent a fair number of years maintaining legacy code in different languages and environments. This made the disappointment even more acute when the book did not live up to its subtitle: A Handbook for Debugging and Optimizing Legacy Code.

The beginning of the book looks promising. The author begins by looking at some of the non-technical forces that influence the success of a software project. He covers the need for sign-off and the importance of a paper trail. He talks about scope creep and complexity. This seems like a really good introduction to the parts of software development that most developers don't think about nearly enough.

The last chapter of the book ties back to these concepts, extending the list of non-technical challenges that hamper getting work done. Topics like fashionable technology, the lack of privacy at work, marketing hype, and other issues that we technical types tend to ignore have a huge impact on your ability to get work done. This chapter does a decent job of making you aware of each of these issues without digging into too much depth. Some of these issues are touched in other parts of the book as well.

Unfortunately, the author does not develop these points further in the book. These topics would be a wonderful education for people coming into software development. It would also serve as vindication for those of us who have seen more of this and realize how much these issues overwhelm the technical issues. What really bugs me is that this isn't the material the book claims to cover.

Starting in the middle of chapter 1 and extending through chapter 6, is what should be the meat of the book. The author's discussion of coding techniques and tools is weak. The book contains technical errors. Some of the source code has major flaws, like refactorings that generate code that is as bad as the original. The best is the memory pool example in chapter 5 that doesn't even use the pool code he wrote.

The author regularly states his opinions as fact without supplying any proof or hard statistics to back up these claims. I was amused by the assertion that the original developer would know enough to make changes to the project without having to relearn everything, but they are never around. He also points out that there wouldn't be bugs in the programs if the original developers had just done things correctly. Actual experience does not support these claims.

I think my favorite unsupported claim is the suggestion that virtual memory is an anachronism, that is unnecessary now that we can get machines with 2GB of RAM. He seems to be forgetting that modern multi-tasking operating systems would be pretty much useless without virtual memory.

In chapter 1, the author develops a logging library, a unit testing library, and a profiling tool. Yet, he spends no time talking about free tools that already fill these needs. He focuses a significant number of pages in the book to constructing some rudimentary debuggers to show how debuggers work, but spends almost no time discussing features of real debuggers that could actually help a maintenance programmer solve problems.

His debugging advice was relatively straightforward. The best of his advice is covered more completely by other books (like Code Complete or The Pragmatic Programmer), some of which have been out for many years. His optimization advice is better ignored. After suggesting that minor tweaks are a bad idea, he spends around a hundred pages telling how to save 5 machine instructions here and 10 over there. After all of these he mentions the concept of picking better algorithms as a quick fix.

All in all, the book does not do a very good job at what it claims to do. The debugging and optimizing information just isn't there. It does have some good information about the non-technical challenges of development; but I can't see wading through the rest of the book for these nuggets. Hopefully, the author will combine the first part of chapter 1 with chapter 7 as the core of a really good book on the non-technical part of development.

I really hoped I would be able to recommend this book, but I can't.