Injection of Failure – Breaking your code on purpose

I’ve had a post by Kent Beck sitting in a browser window for a few weeks, waiting to be read. That’s how I roll: I pile up open browser windows and tabs, promising myself I’ll take a minute to read whatever new shiny thing I’ve found, and then maybe a few weeks later I’ll get to it. Not the best system, I admit. However, it is about the only way I get things read.

So Kent’s post is titled “Hit ‘Em High, Hit ‘Em Low“, and in the post he describes a debugging technique he calls the Saff Squeeze. It is very similar to a technique that I was taught when I was a junior programmer by my good friend and mentor John Petts. Up until now I’ve just called the technique “break it on purpose”. If I knew we were honoring people with names for things I would have given it a better name, like “the Petts Awesomeness” or something. Still, a name would be good, and Saff Squeeze isn’t really working for me (no offense to either Saff or Beck). If we continue Kent’s football metaphor we might just call it “Intentional Grounding”, but I’d prefer to think of it as “Injection of Failure”.

In Kent’s post he describes the technique in unit-testing and refactoring terms: You have a test that doesn’t work and you can’t spot the problem. So you inline your code-under-test which allows you to move your assertion(s) up through the inlined code until you find the error.

This technique is not limited to unit tests and doesn’t require refactoring. It does require a willingness to break things. That’s about it. Here’s all there is to it:

If you have an error in your code but you can’t tell exactly where that error is, create your own error that you understand and try to place it in the code before the error you’re hunting for.

When I was first taught this trick I was a C++ developer trying to troubleshoot a complicated build that had started failing after I pulled in code from another project. But this technique works great in any complicated system. I’ve used this technique recently to diagnose problems with Django, a Python-based web application framework which can sometimes generate very mysterious error messages. But the place that I’ve had the greatest success with this technique is diagnosing Javascript errors in the browser, where development is often like eating noodles with one chopstick.

The one refinement to this technique that Kent doesn’t mention is to use a binary search to find the bug. If there are a 100 lines of code and you know the error is in there somewhere, inject your own error right in the middle of that code. If the error message or program result changes, you know that the bug lives in those last 50 lines. Otherwise it is in the first 50. Then you repeat, moving your injected error halfway through the remaining code each time, until eventually you find the offending line(s) of code.