Debug your code with a doctor's way of thinking

"Now programming is like doing scientific research on the parts of the process that you need to solve. ”
--gerald Sussman

Designing and maintaining good software is like a never-ending struggle to resist complexity. Code paths and components for any size-sufficient application can quickly grow into a dizzying combination of explosions.

It's not a simple thing.

When you deploy a platform similar to Heroku and AWS, a single-server Web application becomes a distributed system. Modern browsers blur the line between the client and the server. When simple programs run on multiple CPU cores, they become complex coordination issues. While guidance such as practice and solid principles such as test-driven development can help us to simulate problems and simplify solutions, most software applications are complex systems where each component interacts and combines in unexpected ways.

When an unexpected situation occurs in a software system, it can cause serious consequences. Fortunately, software developers can draw on another, more ancient discipline, to address the concerns, maintenance, and commissioning of complex systems: medicine.

Differential diagnosis is a systematic method used by doctors to match a series of symptoms and their probable causes. A good differential diagnosis consists of the following 4 steps:

1. Lists all the observed symptoms.

2. List the possible causes.

3. Prioritize these causes.

4. Test in order of precedence to exclude the cause.

Although the above 4 steps are for doctors, we can also think like a doctor and use a powerful way to find and eliminate software flaws. Break down the diagnostic process into one single goal step to ensure that each step deserves the attention it deserves. Priority is given in order to ensure focus on the inspection and to make practical interventions. Then test and exclude assumptions to ensure rigorous commissioning.

The whiteboard is a good thing.

When mistakes occur, most of us think and don't want to investigate the most probable cause. Understanding the backward tracking and a little background knowledge, human nature will tend to speculative doctrine. But a good diagnosis begins with the symptoms listed, not the cause. Write down all the symptoms that can be observed, whether it's exception handling or error code, even if it's just an abnormal behavior. You can use a text editor or Whiteboard, but it's important that you take notes on every step of the diagnostic process. Separate observations from assumptions help ensure that you do not exclude or ignore potential causes. And most of the time, listing more symptoms will narrow down the possible range, and avoid wasting your time on incorrect assumptions.

After you've written a series of symptoms, you can start thinking about why.

Zebra and horse

"When you hear a horseshoe, you're looking for a horse, not a zebra." ”

The likelihood of code bugs appearing in an application is greater than the likelihood of bugs appearing in the web framework, and finding bugs in the web framework is easier than finding bugs in the operating system. Of course it's a good idea to let someone else review the code, but the truth is that most bugs are particularly boring to review. So give the simplest explanation before you start thinking about advanced to more complex issues.

Then again, just as a symptom may be a completely different cause, so we should write down all the related causes we can think of. Just as we described the symptoms directly as "what", and later with "how", the purpose of brainstorming is to use "how likely" to distinguish "how". Capture any plausible points to save analysis.

The weight of the heavy, not harmful

Differential diagnosis differs from other deductive methods because doctors must constantly assess the risk and weigh the impact on the patient's life. Of course, if there is a bug in our product, though it will not be as serious as the life responsibility of the doctor, the pause repair will produce both realistic and painful cost costs. As with life-threatening disease events, immediate intervention is required, and serious bugs may require rough, simple fixes, such as rollback and restart. Prioritize the assumptions, then consider the tradeoffs, and decide whether to start the test hypothesis or intervene immediately.

Prepare the chart

As the patient will have a chart of the hospital history and other background information, your software system may also need to have a chart. Collect information from the log and error reporting system to illustrate your analysis. As for system indicators and tracking errors, you might as well use them as sensible preventative drugs.

If your patient is not in serious danger, then you can assume-deductive. Starting with the highest-priority assumptions that you define, one by one proves that they are wrong. Although supportive evidence may sometimes help you find the bug, the failed test drives the deductive process. This may seem counterintuitive at first glance, but testing-eliminating a hypothetical strategy is the quickest way to trace a bug to its cause. In many cases, some simple tests can eliminate several assumptions at a time. Of course, there are times when you have to perform more tests in order to veto the hypothesis.

Laboratory work

Unlike the medical world, it's hard to accept that you can clone software applications and perform scary human experimentation whenever you want. If you have enough information to trigger the bug you want to diagnose, you can copy it to a managed environment, such as a temporary server with the latest database backup. When you destroy the cause, collect the new data, and refine the assumptions, the clues to the real cause of your bug will become clearer.

Think clearly about the care and focus that complex systems require. The use of structured diagnostic procedures to guide inspection can save time and avoid frustration. Most importantly, it is very useful. The next time you're stuck in a bug, try tossing the keyboard and writing the steps step-by-step to the whiteboard and debugging like a doctor.

Debug your code with a doctor's way of thinking