A root cause is the condition behind a failure rather than its visible symptom. Finding it prevents a fix from merely moving the problem elsewhere: start by clarifying what happened, gather evidence, and trace the failure toward its origin. section 10.3.2 section 10.4
When a failure is reproducible, use hot exploration. Trigger the error, observe where it first appears, and follow evidence through consoles, network traces, logs, and stack traces. A broken web form, for example, may initially look like a frontend problem; an HTTP 500 response can redirect the investigation to backend logs and the faulty line of code. section 10.3.2
When reproduction is impossible or intermittent, use cold exploration. Build a timeline from the first report and reconstruct events from logs, metrics, and traces. This route demands more inference, because the decisive clues have already passed. section 10.3.2 section 10.4
Treat a suspected root cause as a hypothesis until evidence supports it:
- Clarify the context, effects, reproducibility, recent changes, and available diagnostic data. section 10.3.4
- Investigate beyond symptoms, using the 5 Whys, sketches or mind maps, documentation, forums, colleagues, or AI assistance to expose possible links. section 10.3.4
- Evaluate competing explanations with diagnostic tools, changed log levels, dumps, or temporary fixes; discard explanations that do not fit the evidence. section 10.3.4
- Implement a validated fix, add a missing unit test when appropriate, and check that the change creates no side effects. section 10.3.4
An intermittent production crash
A Java application crashed only under production load. Logs revealed heap out-of-memory exceptions, and a stack trace led to Excel export code. A heap dump showed several exports running concurrently with other memory-heavy work. The underlying problem was not simply an undersized heap: workbook generation retained all rows and intermediate objects in JVM memory until finalization, which became unsafe with concurrent production exports. section 10.3.4
Root-cause analysis can loop. Implementing a proposed solution may reveal information that was not visible earlier, requiring another round of clarification or investigation. The practical goal is a confirmed explanation and a safe remedy, not the first plausible story. section 10.3.4 section 10.4
Design for diagnosis before failure arrives. Robust failure handling should preserve meaningful clues that help trace causes, while avoiding mishandled errors for users. Logs, traces, and diagnostic artifacts are therefore part of system design, not only incident response. section 7.0
Table 10.1 The creative problem-solving methodology
|
Step
|
Goal
|
Means
|
|---|---|---|
|
Clarify
|
Build a precise understanding of the problem before acting.
|
Ask targeted questions to understand the context and effects, reproduce the problem if possible, gather logs, dumps, and metrics, review recent changes, and perform a hot (live) or cold (postmortem) exploration to collect clues.
|
|
Investigate
|
Search for the root cause behind the symptoms.
|
Apply the 5 Whys method to trace each symptom to its origin, use mind mapping or sketchstorming to uncover hidden links, and seek outside input by checking documentation, searching forums, asking a colleague, or consulting an AI assistant.
|
|
Evaluate
|
Test each hypothesis to confirm or discard possible causes.
|
Adjust log levels, capture new dumps, use diagnostic tools, or apply temporary fixes to verify assumptions. Pause when needed to let ideas incubate.
|
|
Implement
|
Apply the solution.
|
Fix the root cause, add or improve unit tests, validate for side effects, and document the resolution.
|
Use the four-step methodology as a navigation aid: clarify the failure, investigate possible origins, evaluate hypotheses, then implement and reflect on the validated solution. section 10.3.4
