Software Exorcism: A Handbook for Debugging and Optimizing Legacy Code (Expert's Voice)

Don't give this one to your programming team, they probably won't get it. Don't give it to this year's star programmer, for the same reason. Wait until you find that one kid that always has one more answer than everyone else, and especially the one that has one more question than everyone else. Give that kid this book.This book is about all that ugly stuff that people take pride in ignoring because it's "low level" and they're way too cool to do anything low. Memory has costs, CPU cycles have costs, they're wasted in different ways, and recovered in different ways. You find out which is which in different ways. That's what this book is about. Basically, it's all that stuff that was too pragmatic for your CS professors and too theoretical for the Computer Eng. teachers - i.e., what you needed and never got.This book addresses memory usage, stack frames, processor cache, loop fusion and strength reduction, all in down-and-dirty examples. It talks about debuggers, source control, and bug management - the facts of daily business life that coursework rarely addresses.If a junior zoomer masters what this book has in it, s/he might survive one of my favorite interview questions: Given only a C compiler, no assembler, and full compiler documentation, unwind the stack. If you don't know what "unwind" is, go away; if you read this book, we'll talk.//wiredweird

Books about debugging that share experiences are amusing. This book is very interesting as it presents the debugging as an exorcism. In the catholic rite of the exorcism the priest demands the evil spirit to leave the body of the possessed person, this is the task we are faced sometimes in software development.Sometimes it seems that our software acts by its own and demands an exorcist to throw away the evil bug spirit that possesses it. It's a metaphor but very worth reading.

Very good! This is not only an amazing technical book but it's also a politician book about the truth behind the software industry. All I have to say is that you must read it before you even think about rate yourself as a "good" programmer. But like everything in life it has only one big problem. The author states that by using a debugger you run out of "Heisenberg principle" and it's not true! The effect that a debugger has on timing related problems is not trivial. Even made a debug build will change timing. Anyone who had problems with threads once in life, will know how hard is to debug a thread problem with a debugger (or debug build), just because as your program slowdown your threads may work fine and you will never know what's happening to your concurrency management. Debug without change timing only work for single thread process and only those ones that do not take timing on account to work properly. By the way, I must recommend this book; you will find a lot of useful tips & tricks on it!

Bill Blunden is clearly an experienced maintenance programmer. He is also someone who has clearly worked in the snake-pit of the commercial world. He has a lot to say on how to approach the maintenance of legacy code. He is right on the money when comparing the debugging process to the use of the scientific method, although I think, for the benefit of those new to the idea, he could have gone into greater depth on how experiments should be constructed. (Basically, you've got to know what the results mean BEFORE you run the experiment.) Also, he is correct in his advice on when to optimize software: only after you've used a profiling tool to identify the bottlenecks. In my experience, humans are bad at guessing where the bottlenecks are; let the computer do it.If you've been sensing a "but" coming, here it is: he seems to have stopped paying attention to developments in C++ sometime in the mid-90's. Of the sins committed in his C++ examples (of fixes, not of bad code) are: failure to use the C++ standard library, throwing pointers to exceptions, not deriving exceptions from std::exception and failing to use the built-in bool type in favor of C-style TRUE and FALSE. Also, most of the techniques he mentions in he section on CPU optimization are things that optimizing compilers have done since the early 80's (or earlier).The strength of this book is in the sections on debugging and dealing with legacy code. He deals well with the political side of this profession. I have not seen this dealt with elsewhere. Less useful are the sections on the techniques of optimization.He calls software engineering a "young man's game" because the efforts required to keep up with the latest fads in software becomes prohibitive after a while; all those new kids just out of school will already know this stuff and will work for less to boot. I am a professional software engineer. I have a long experience with software maintenance. Like any professional, I feel that it's part of the job to keep up with current practice. Does that mean following every fad? No. It does mean learning about those things that have survived fad-dom. That's why I bought this book.

Nice book which mirrors a lot of my experience with software development. It contrast to most books it does not talk about ideal software but what you will experience in real-life, so it is complementary to most software books