35   Attack Problems in Isolation

“Stepping line by line through a massive code base is pretty scary. But the only way to debug a significant problem is to look at the entire system. All at once. After all, you don’t know where the problem may be, and that’s the only way to find it.”

One of the positive side effects of unit testing (Chapter 5, ​Agile Feedback​) is that it forces you to layer your code. To make your code testable, you have to untangle it from its surroundings. If your code depends on other modules, you’ll use mock objects to isolate it from those other modules. In addition to making your code robust, it makes it easier to locate problems as they arise.

Otherwise, you may have problems figuring out where to even start. You might start by using a debugger, stepping through the code and trying to isolate the problem. You may have to go through a few forms or dialogs before you can get to the interesting part, and that makes it hard to reach the problem area. You may find yourself struggling with the entire system at this point, and that just increases stress and reduces productivity.

Large systems are complicated—many factors are involved in the way they execute. While working with the entire system, it’s hard to separate the details that have an effect on your particular problem from the ones that don’t.

The answer is clear: don’t try to work with the whole system at once. Separate the component or module you’re having problems with from the rest of the code base for serious debugging. If you have unit tests, you’re there already. Otherwise, you’ll have to get creative.

For instance, in the middle of a time-critical project (aren’t they all?), Fred and George found themselves facing a major data corruption problem. It took a lot of work to find what was wrong, because their team didn’t separate the database-related code from the rest of the application. They had no way to report the problem to the vendor—they certainly couldn’t email the entire source code base to them!

So, they developed a small prototype that exhibited similar symptoms. They sent this to the vendor as an example and asked for their expert opinion. Working with the prototype helped them understand the issues more clearly.

Plus, if they weren’t able to reproduce the problem in the prototype, it would have shown them examples of code that actually worked and would have helped them isolate the problem.

The first step in identifying complex problems is to isolate them. You wouldn’t try to fix an airplane engine in midair, so why would you diagnose a hard problem in a part or component of your application while it’s working inside the entire application? It’s easier to fix engines when they’re out of the aircraft and on the workbench. Similarly, it’s easier to fix problems in code if you can isolate the module causing the problem.

But many applications are written in a way that makes isolation difficult. Application components or parts may be intertwined with each other; try to extract one, and all the rest come along too.^[35] In these cases, you may be better off spending some time ripping out the code that is of concern and creating a test bed on which to work.

Attacking a problem in isolation has a number of advantages: by isolating the problem from the rest of the application, you are able to focus directly on just the issues that are relevant to the problem. You can change as much as you need to get to the bottom of the problem—you aren’t dealing with the live application. You get to the problem quicker because you’re working with the minimal amount of relevant code.

Isolating problems is not just something you do after the application ships. Isolation can help us when prototyping, debugging, and testing.

Attack problems in isolation. Separate a problem area from its surroundings when working on it, especially in a large application.

What It Feels Like

When faced with a problem that you have to isolate, it feels like searching for a needle in a tea cup, not a needle in a haystack.

Keeping Your Balance

• If you separate code from its environment and the problem goes away, you’ve helped to isolate the problem.

• On the other hand, if you separate code from its environment and the problem doesn’t go away, you’ve still helped to isolate the problem.

• It can be useful to binary chop through a problem. That is, divide the problem space in half, and see which half contains the problem. Then divide that half in half again, and repeat.

• Before attacking your problem, consult your log (see ​Keep a Solutions Log​).