Troubleshooting Rule #4: What's changed since it worked?

Sometimes when troubleshooting, you look at the problem very closely as it exists now. But in many cases, you can look back at what things were like before the problem existed. What worked then, and what has changed since that time?

In software, version control or change management tools make this simple. If the problem occurs in uncommitted code, you can see your changes directly via git diff etc.; if not, bracketing the source tree (using a binary search through time until you see when the problem first occurred) can help focus your attention on a small set of code changes that triggered it.

In other contexts, you may not have that much documentation. Think about that for next time—the more you document about creative processes or social structures, the more tools you’ll have available when things go wrong. If you wish you could look back at what had changed, start documenting those changes from now on.

You may have to rely on your memory. You can help improve your retrieval of pertinent facts by taking a structured approach: write down what you remember of what changes were made, in time order, and take several passes. It can also help to brainstorm and write down ideas about what could have changed invisibly, without anyone intending to make a change. Did a wire fall out? Did the Internet go down? Did some job get done by someone new?

When did it get broken?

Next rule: What don’t you know?