Extraction Over Refactoring

Code is cheap. Alignment is not. Chapter 5 opens on the response most organizations reach for once they recognize the legibility problem: schedule a refactor. Clean up the accumulation, and the navigation problem resolves, or so the reasoning goes.

The chapter makes the case that this is a trap, not a fix. A refactor consumes an organization's most senior engineers for months, and produces cleaner services, better names, a codebase a new developer can read without flinching. What it does not produce is a system that declares what it knows. Point an agent at the refactored system, and it fails for the exact same reasons it failed before the first planning meeting, because legibility is a property of declared contracts, not clean code.

Extraction is the alternative: pull one capability out of the legacy system, contract it properly, and leave the rest untouched until it's its turn. The chapter lays out how to prioritize what gets extracted first, and why progress that compounds beats a rewrite that has to finish before it pays off.