For many developers, debugging is about making problems go away, not understanding the system. This fundamental misalignment perverts every aspect of the process and leads to:

• fixes that don't actually fix the problem (or worse, introduce new ones)
• bug reports that are unceremoniously closed out as "works for me" or "can't reproduce" or "will not fix"
• frustrated users who are told to "try restarting" or "log out and log back in"

As bad as these are, much more insidious effects are felt when a problem appears to be debugged but hasn't been truly understood or resolved. These ersatz fixes are worse than nothing: not only do they leave the fundamental problem in place for another day or another customer or another outage (one that might have manifestations that are more subtle or more damaging or both), they give the software engineer the distorted sense of having resolved the problem and this false confidence leads to new development and different bugs -- and debugging devolves into collective superstition passed on by oral tradition.

Our view is that debugging is an essential part of the craft of software development. By thinking of debugging as a primary endeavor, developers are liberated to be more rigorous about it and can afford the luxury of complete understanding. By considering debugging as opportunity rather than setback, developers can take a craftsman's pleasure in it, mastering its nuances and deriving intrinsic satisfaction from doing it well. This is the thesis of this book: that debugging must be rigorous and empirical -- but that within that rigor, software engineers can discover a joy unique in the craft.