functional-diagnosing-complexitylisted

# Diagnosing Complexity ## Overview Complexity is anything about the structure of a system that makes it hard to understand or modify. It is not the difficulty of the problem being solved; it is what the code adds on top of that problem. Complexity is what you feel, not what you measure: if the people working in a system find it hard to change, it is complex, whatever the metrics say. Diagnose before you fix. Every complexity has exactly two ultimate causes and shows up as exactly three symptoms. Naming the symptom and tracing it to its cause tells you which design rule to apply. ## When to use - A one-line behaviour change requires edits in five places - Reading a function requires opening four other files first - A change broke something no one predicted it could reach - Estimating a change is guesswork - Before proposing any refactor, so the refactor targets a real cause Not for: performance problems, or code that is merely unfamiliar to you but obvious to the people who own it. ## Is this complexity necessary? Ask this before anything else. Complexity you added should be deleted, and refactoring does not delete it — once accidental complexity has a clean interface and a test suite, nobody removes it. State the requirement in the domain expert's words, using no implementation nouns. Then list what the code contains that the sentence did not mention: flags, caches, orderings, adapters, intermediate representations, defensive checks. Everything on that list is **acc