Compound Defects

In the five step process that I detailed last week, we assumed that the defect was highly localized. What do you do if the issue you're seeing is actually the result of multiple defects in different places?

The process still works, but you need to make sure you really nail steps 1 and 2. For reference, here are the steps again:

  1. Ensure you can clearly articulate the symptoms of the defect and reliably reproduce it
  2. Define the boundaries in your code within which the defect could exist
  3. Form a hypothesis about the cause
  4. Test hypothesis
  5. Begin again at Step 1 until you can demonstrate unambiguously that the defect has been resolved

If you have well-defined boundaries in your code (see Step 2), you can treat each component as a separate debugging process, then bring them together. For instance, suppose you have a React component that renders a list, but is throwing an error. When you investigate, you find that the endpoint that feeds this list is returning an empty array where you expected a populated list of objects.

This is actually two defects. You need to fix the endpoint to return the expected set of objects, but you also need to fix your React component to handle cases where it may correctly receive an empty list from the API.

If you have clearly defined behaviors for both the endpoint (it returns an array of objects or empty array based on query params x, y, and z) and the list component (it renders a list provided an array, or an informative message if the array is empty) then you can apply the process independently to each component, then revisit the behavior of the whole.

Next Up:
Don't Forget the Obvious

Previously:
Your Five Step Debugging Guide: Part 5


Want to impress your boss?

Useful articles delivered to your inbox. Learn to to think about software development like a professional.

Icon