Debugging is the hardest part of programming to describe systematically, because its very purpose is to deal with unsystematic behavior. A programmer plans for a program to behave in a particular way; debugging is what happens after the programmer discovers that the program is not behaving as planned. As a result, it is hard to write — or even think — about debugging in general. Every bug is different, so saying something that applies to the act of debugging requires finding something general to say about a bunch of unrelated specific cases that defy generalization by their very nature.

From this description, it is easy to see why debugging is like art. Art takes a part of our experience and distills it in a way that expresses the artist's personality. Different programmers will attack the same debugging problem differently, just as two different artists will portray the same scene differently. Moreover, although art encompasses many techniques that can be described in detail, written about, and taught, there is an inspirational core that is an essential part of each artist. Similarly, highly skilled debuggers often have difficulty describing how they came up with the idea that ultimately led them to the bug they were hunting.

Despite these similarities, I think that debugging is more science than art. To explain this viewpoint, I'd like to start with a particular view of what science is.

At its core, science is the process of modeling the physical world. Here, I am using model as a physicist or mathematician might: to describe an intellectual structure (such as a collection of equations) that behaves in ways that match some (but not all) of the properties of the physical world. There is much art in choosing such models in the first place, so it is fair to say that there is much art in science. However, where science differs from art is in how it deals with a model that does not match reality.

A work of art is always inaccurate; that's its point. If you set out to make a statue of an elephant, there's no art in simply using an elephant for the purpose. Yet nothing is as much like an elephant as an elephant is; which means that there will always be differences between any artistic representation of an elephant and an actual elephant. A model, however, is not an artistic representation. Although it is most useful if it is accurate, it does not attempt to be complete. Its purpose is only to explain — or predict — some aspects of the behavior of what is being modeled. So, for example, if someone can come up with a robot that behaves similarly to an elephant, but happens to be small enough to fit in the palm of one's hand, the size discrepancy is not relevant to the model's purpose. For the purpose of validating a model, it might not even be necessary to build a physical robot. The software itself might suffice.

In short, discrepancies between the world and its representation are a necessary part of art. In contrast, such discrepancies in scientific models are either irrelevant or something to be studied and reduced. This study and reduction is a fundamental difference between art and science.

A program is like a scientific model. We have an idea of what we would like that program to do; when we write a program, we want to make it behave as much as possible according to that idea. When our program does not behave that way (i.e., when we encounter a bug), we follow what is essentially a scientific process:

• Is the difference between the model (i.e., the program) and reality (i.e., how we want the program to behave) what we think it is? For example, are we running the right program? Can we reproduce the misbehavior consistently?
• Can we come up with a hypothesis that explains the difference between the model and reality? This step is probably the most creative part of debugging, just as it is the most creative part of science.
• Once we have a hypothesis, how do we construct an experiment to test the hypothesis?

If our experiment shows that the hypothesis is correct, our debugging task is finished — at least for now. If not, the failed experiment may reveal how we were incorrect about the first step, namely finding the difference between the model and reality. After understanding how our hypothesis was incorrect, we can repeat the process with a new hypothesis.

There is no question that this analogy between debugging and scientific experimentation allows for much creativity, especially in the area of forming hypotheses. However, not all creativity is art, and there is more creativity in systematic experimentation than may appear at first glance. As a result, despite the creativity that so often goes into debugging, I think that debugging is more science than art.