<commit_before>[[pattern-root-cause-analysis]]

=== Root-Cause Analysis 
[quote, <NAME>]
To find mistakes is not enough. It is necessary to find the cause behind the mistake
and build a system that minimises future mistakes. 

==== Intent
Explicitely differentiate between symptom and cause: 

* Identify root causes of symptoms, problems or issues
* Trace a problem to its origins

==== Description
Some people fight problems, not their real cause:

==== Experiences 

[TIP]
--
Users of a system complained about _low performance_. 

Developers started tuning the database,
tweaking the application server, optimizing inner loops and so on (you pretty well know what I mean).

That did not solve the issue. 

After applying <<Take-What-They-Mean>> we found out that users complained about low performance in data entry,
as they had to switch back-and-forth between different regions on their input-screens.

The actual _cause_ of their complaint was the improper field order in their input forms. After adapting this
order by simply dragging fields/labels around the screen, users were perfectly happy with the systems.
--


==== Applicability
when-and-where-is-this-pattern-applicable

==== Consequences
You can eleminate the cause, 


==== Also Known As
* Inspect-Cause
* Separate cause from effect

==== Related Patterns
* <<Take-What-They-Mean>>, maybe what they told you was not the real problem.

==== References

* http://en.wikipedia.org/wiki/Root_cause_analysis
<commit_msg>Added some more details to Root-Cause-Analysis.<commit_after>[[pattern-root-cause-analysis]]

=== Root-Cause Analysis 
[quote, <NAME>]
To find mistakes is not enough. It is necessary to find the cause behind the mistake
and build a system that minimises future mistakes. 

==== Intent
Explicitely differentiate between symptom and cause: 

* Identify root causes of symptoms, problems or issues
* Trace a problem to its origins

==== Description
Some people fight problems, not their real cause: When faced with a problem our brains tend to start immediatly to search for proper solutions for exactly this problem. E.g., if our application regularly crashes with Out-Of-Memory-Errors it might be a reflex to increase the memory settings. Instead we should ask if this is really the problem or only a sympton of the real problem, e.g. a programming failure in memory releasing. With an iterative process of asking "Why?" the causal chain must be traced down to the root cause.

==== Experiences 

[TIP]
--
Users of a system complained about _low performance_. 

Developers started tuning the database,
tweaking the application server, optimizing inner loops and so on (you pretty well know what I mean).

That did not solve the issue. 

After applying <<Take-What-They-Mean>> we found out that users complained about low performance in data entry,
as they had to switch back-and-forth between different regions on their input-screens.

The actual _cause_ of their complaint was the improper field order in their input forms. After adapting this
order by simply dragging fields/labels around the screen, users were perfectly happy with the systems.
--


==== Applicability

This pattern should always be considered when faced with a problem.

==== Consequences

You can eleminate the cause, 


==== Also Known As

* Inspect-Cause
* Separate cause from effect

==== Related Patterns
* <<Take-What-They-Mean>>, maybe what they told you was not the real problem.

==== References

* http://en.wikipedia.org/wiki/Root_cause_analysis

{'fraction_non_alphanumeric': 0.07006550840216462, 'fraction_numerical': 0.0, 'mean_word_length': 4.411402157164869, 'pattern_counts': {'":': 0, '<': 13, '<?xml version=': 0, '>': 13, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7247875', 'n_tokens_mistral': 931, 'n_tokens_neox': 858, 'n_words': 472}