Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code

by Bill Blunden

l IT HAS BEEN DOCUMENTED that the maintenance phase of the typical software project's life cycle accounts for over 60 percent of the total cost incurred. For all the pomp and circumstance heaped upon the design phase, once the first release has been deployed, most of the resources will be spent on fixing bugs, adding new features, and fixing bugs resulting from those new features. The post-release development cycle of the average software application resembles that shown in Figure 1. 1. Don Coleman et al., "Using Metrics to Evaluate Software System Maintainability," IEEE Computer, August 1994, pp. 44-49 xv Introduction Debug Test Profile Optimize H H H t I Test Debug I Add feature H H t Figure 1. Post-release life cycle o/the average software application The post-release cycle can be initiated by the addition of a new feature or the submission of a bug report. In either case, unit and system tests are used to determine if the patched code is doing what it is supposed to. Once the paths of execution have been sufficiently stabilized, the application can be profiled to locate performance bottlenecks. A variety of optimization tech- niques can then be implemented to increase execution speed and decrease memory footprint. As customers demand new features and report new bugs, the cycle will repeat itself and the application will evolve. Most books on software engineering focus intently on the phases of development leading up to the release of an application (e. g.

Genres: Programming, Reference, Computers

399 pages, Paperback

First published January 1, 2003

Reviews

[Peter Aronson · Rating 3 out of 5]

I have to admit -- at least 75% of the reason I bought this book was the irresistible title. As other reviews have noted, this book is aimed at new, not experienced, maintenance programmers, and it is rather out of date in places. It is also deeply cynical about the human and culture issues it addresses. I wouldn't actually give it to a new programmer without some warnings about that. But for all that is wrong with it, the author has an engaging writing style, and has clearly has plenty of real world experience (apparently, though, at some deeply dysfunctional companies).

It encourages you to read code, which is good, and its emphasis on understanding what the software is supposed to be doing is excellent. The advice of how to structure code to make future maintenance is not awful, if rather dated in places.

The book spends a bunch of time talking about debuggers, and even shows how to implement very primitive debuggers. That's harmless and even interesting, if mostly out of date. However, the optimization advice is OK when it is general, but much of it could be actively dangerous if actually applied. And the writer is no prophet the changes he saw happening to the field still haven't happened and probably won't the way he saw them. (He also didn't foresee the cloud, but at time, who did?)

But despite the shortcomings, I don't regret taking the time to read this book.

[Dana Robinson · Rating 2 out of 5]

I picked this up because I found his Cube Farm book to be a funny memoir, but I'm disappointed. There's some useful info here, but most of the book has little depth and/or is quite dated in 2022. Probably a third of the book involves code examples that are a bit silly given that open-sources software exists that does the same thing. Encouraging people to reinvent the wheel is just weird. Perhaps the bits about collecting a paper trail are useful if you are in a hostile work environment, but that's about it. Even if I were reading this shortly after it was published, I'm not sure I'd get a lot out of it. Other books age much more gracefully than this one.

[Carter · Rating 3 out of 5]

Covers a hodgepodge of topics related to testing, debugging and some random thoughts on the corporate world. Generally an okay book but not too useful for me since I have read more detailed treatments of most these topics elsewhere.

[Niranj · Rating 3 out of 5]

This book is not for a seasoned professional - most of the tips and tricks discussed in this book should be familiar to someone with a couple of years of experience. However, I found that this book spoke about several concepts that I had to learn on the job, early in my career. I also made a few mistakes as pointed out in the book which I could have avoided, had I read this book 10 years ago.

The book mostly discusses examples with C/C++ code, but the concepts should be easily extendable to any programming language. Most large organizations seldom develop software products from scratch, and in this aspect, knowing how to maintain and debug code written by someone else is a valuable skill. The book also goes ahead and teaches a few good aspects of programming. More than programming, the book also talks about management/people issues that one generally has to learn the hard way (key skill needed, apart from technical knowledge, so that you don't suffer later).

If you're a recent graduate and working in a maintenance project, I'd very strongly recommend reading this book, if you haven't already. The book discusses tools and code based on DOS/Windows NT which some may feel are outdated. But for someone who's learning to maintain code, this shouldn't be a hurdle - you can always find equivalents to the operating system of your choice. Either way, if you work on any maintenance project, give this one a read - you may learn something that you already didn't know.