Why Programs Fail is a straightforward collection of hard-earned knowledge about the task of figuring out what's wrong with a computer program and how to fix it; as the subtitle notes, it is "A Guide to Systematic Debugging".
Many programmers simply never develop their debugging skills, and hence they are at best inefficient and at worst ineffective at debugging. Zeller sets out to help you past these problems, by showing you tools and techniques that will make you a more efficient and more effective finder and fixer of bugs in programs.
Professor Zeller is well-known as the author of the ddd graphical debugger on Linux, and the delta debugging algorithm, which later became the delta debugging tool, so it is no surprise that some of the strongest sections of the book are the ones which describe how to use debuggers effectively. Chapter 8 describes, in detail, how to use the gdb debugger to step through programs, examine state, interpret the debugger displays, control the program's behavior, etc.
I liked several other sections of the book as well. For example, chapters 3, 4, and 5 do a good job of presenting lots of different ideas and strategies for reproducing problems, writing tests to demonstrate problems, narrowing down test cases, making unreproducible problems easier to reproduce, etc.
And there are some nice little tid-bits sprinkled throughout the book that show that the author knows of which he writes. For eaxmple, when discussing the need to re-run the bug script after fixing the bug (to demonstrate that you've actually fixed the bug), he notes that you may find that the script still fails even after your fix, in which case:
Being wrong about a correction should:
- Leave you astonished.
- Cause self-doubt, personal re-evaluation, and deep soul searching.
- Happen rarely.
Not everybody cares this much about fixing bugs, but it's wonderful to feel the passion of somebody who does. And then, later, when Zeller reflects on what you should do after you've fixed the bug, in a section titled Learning from Mistakes, he suggests:
- Improve your test suite.
- Test early, test often.
- Review your code.
- Improve your analysis tools.
- Calibrate coverage metrics.
- Consider mutation testing.
It's a great list, and it's even better to see people pushing the point that bug fixing doesn't stop with fixing the bug; you need to take that opportunity to try to figure out (a) how the bug got there in the first place, and (b) how come it took so long to find it.
I probably won't go forcing this book on people who haven't asked me about it, but I definitely didn't consider it to be wasted time. If you've got some time and energy, and you're interested in improving your practical programming skills, go check it out!
No comments:
Post a Comment