The most dangerous rewrite is the confident one. Some fences exists for a reason. Do you know what is that?
There is a principle in philosophy called Chesterton's Fence: don't remove a fence until you understand why it was built. The person who tears it down without asking why is not being efficient. They are being dangerous.
Software has fences everywhere. A redundant validation. An inexplicable retry loop. A module marked for deletion that somehow never got deleted. Most developers want to remove them. And most do — during a rewrite.
This is where the tester's job begins.
Developers approach legacy code looking for what to change. Testers need to understand what to protect. When nobody does the second job, the rewrite inherits none of what the old system learned. The fence gets torn down. And months later, everyone finds out why it was there.
Legacy code is not bad code. The tester who can read that memory is producing something the rewrite team cannot build without them: a map of what the system was once afraid of.
I.What developers see and what testers look for: the test suite as a fear map. Not a quality metric, but a record of what the system has survived. We examine one real case without a map and what it cost.
II.How to read survived code: Three techniques: following the oldest unfixed bugs; tracing which modules consistently break together; identifying tests no current requirement explains.
III.The fence-mapping framework: A portable checklist of three diagnostic questions a tester runs before any significant legacy change or rewrite kickoff.