Bugs are a failure of prediction


Rather, the essential definition of a bug is that we failed to predict what a piece of code would do.


We thought it would do the right thing. The prediction was wrong. So let’s focus not on the broken code, but on improving our predictions.


I like tests not for safety, per se, but because they require us to articulate what a piece of code should do. Further, they require us to interact with our code from the outside (you know, like a user). Safety is a side effect of these two things.



Humans form a mental model of what a piece of code will do. To the extent that understanding a piece of code requires understanding other, possibly far away, pieces of code, we make forming an accurate mental model more difficult.

Code becomes unpredictable by humans when it taxes our mental models.

Playing computer

A few rare programmers can look at a piece of code and know what it will do. Most of us can’t. Instead, we make educated guesses.




Prediction is more likely when a piece of code looks like what it does. This is a very subjective idea, of course.

The best measure is: how often would a programmer new to this code make correct predictions about how it behaves?

This is an argument about abstractions, of course. One person’s “spare me the details” is another’s “too much magic”.

What we call “readability” is in fact predictability.

None of these are new ideas. They are mostly best practices, and we believe they lead to higher quality software.

These practices work, however, not because they “improve code”. Rather, they improve human understanding of code. That distinction is the essence of predicting bugs.

discuss on hacker news

Published by Matt Sherman on February 7, 2015