Best for
- Inherited systems whose authors are long gone
- Due diligence before buying, rewriting or extending old software
- Turning 'nobody touches that module' into documented understanding
What you give it
- The codebase, whatever docs exist (including wrong ones), and your goal
- Business context when it asks what a mysterious behaviour is FOR
What you get back
- A map: components, responsibilities, data flows and the dependencies between them
- The risk atlas: load-bearing hotspots, dead zones, duplicated truths, the scary parts ranked
- Entry-point guides for the changes you actually plan to make
How it works
- Traces real execution paths from entry points, rather than trusting folder names and dead docs.
- Maps data flow: where truth lives, who writes it, which copies drift.
- Uses change history as evidence: what changes together, what breaks often, what nobody has dared touch.
- Ranks risk by blast radius x opacity — the dangerous parts are the load-bearing ones nobody understands.
- Documents against your planned changes, so understanding lands where you need it first.
Example
You: We inherited a 12-year-old order system from an acquisition. The one developer who knew it left.
Result: A map of 9 real components (the folders suggest 23 — most are vestigial), the discovery that pricing logic lives in three places that disagree, a ranked scary-list with the nightly reconciliation job at the top, and a safe-change guide for the two modifications you planned — one of which touches the top of the scary-list, now with eyes open.
Limits — please read
- WHAT the code does is readable; WHY it does it sometimes died with the author — those get marked as open questions, not invented answers.
- Dynamic behaviour (config-driven dispatch, reflection) is mapped as far as static reading and careful running allow, and the blind spots are listed.
- A map informs a rewrite decision; it is not by itself a recommendation to rewrite.