A senior engineer at a mid-size startup inherits a codebase. The tests pass. The service runs. But every time the team ships a feature, something unrelated breaks. Adding a new payment method changes behaviour in the notification system. Fixing a bug in the user service requires touching the analytics pipeline. Nobody planned this. It emerged from three years of growth without deliberate boundaries. The engineers are not bad — the module structure is.
The symptom is clear: changes ripple through code in ways that should be impossible given what the code is supposed to do. The diagnosis requires a different tool than a debugger. It requires examining the import graph.
You have already seen divide and conquer (T8) in Book 1, where large problems are split into smaller problems that can be solved independently and whose solutions are combined. Here it appears at code level as modularity: a codebase is divided into units that can be developed, tested, and deployed independently. The shape is the same — decompose to reduce complexity, recombine to deliver capability. The constraint is the same too: the decomposition is only useful if the pieces genuinely do not depend on each other’s internals.