Troubleshooting Rule #8: Simplify!

If you’ve gotten this far in my troubleshooting rules, this is a tough problem. Maybe you can solve it…

… but maybe instead you can replace the situation with a simpler one that will be less prone to problems?

This dovetails with the famous Brian Kernighan quote:

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”

I summarize this to: Write code [or design any system] only half as cleverly as you can.

If this system, be it software, hardware, or interpersonal, is complex enough that it’s caused you this much trouble, it’s likely to cause even more problems down the road. If you can replace it with a simpler system—one that’s more modular, or with clearer expectations between its parts, or with parts that map better to its purpose, or with more modest expectations—you may find that the trouble is no longer there when you look for it in the new system.

In software, refactoring is a common way to simplify a system. Sometimes you can also find an opportunity for more radical restructuring. Some common forms are:

• relaxing an assumed constraint: “What if we didn’t need to update this in real time with all this data, but streamed it a bit at a time instead?”
• replacing a component: “What if we removed these leaky buttons entirely, and replaced them with capacitive touch sensors under the enclosure surface?”
• refocusing on real user goals: “Users don’t really want to sort by arbitrary columns here, they just want to go through each item in time order and see how many are left.”

Interpersonally, there can come a time when a relationship is simply not working well and there are too many impediments to solving the situation as it is. It can be perfectly acceptable to reassign or even fire an employee, quit a job, break up with a lover, or shift your expectations of a family relationship to something simpler and more likely to work. No blame needs to be laid for these kinds of actions; you can do them without condemning anyone, without shame, and with compassion and clarity. (The details can of course be difficult and take time to work out—humans are complex!)

This is not necessarily the end of the line for troubleshooting—there are always other options, including divine inspiration—but if you’ve reached this point, you should strongly consider ripping something out and replacing it; it may save lots of time and trouble in the long term.

You can also temporarily simplify a system just to find out how to solve the problem. You may find that the problem still recurs in the simpler system, and then there’s so little room for error that the cause is obvious - and then you can transplant the solution back into your original system. Interpersonally, this could look like getting a couple of people in a room or on a retreat, or splitting up a group, or compartmentalizing duties. In software, it can mean making the bug show up with just a simple piece of template code (which will make everyone on Stack Overflow happier too).