Design Rot: Why Working Code Becomes Hard to Change

One small change breaks three unrelated features, and nobody wants to touch the class.

Design rot is the slow loss of a codebase's ability to change. The code still works and the tests still pass, but every new request takes longer than the last, and each one breaks something nobody expected. This card names the four symptoms of rot, so that you can recognise which one you are facing before you reach for a fix.

Picture a small team that runs an online shop. Finance asks them to accept euros as well as pounds. It sounds like an afternoon's work. Two weeks later the change has touched eleven files: the checkout, the receipt email, the database layer, the shipping labels, three reports and the tests for all of them. Along the way the refund screen broke, although nobody had touched it. Nobody on the team wants to open the checkout class again.

None of that came from a single bad decision. Each class was written to solve the problem in front of it, and each one reached directly into whatever it needed. Over a few years those direct reaches piled up until the code resisted every change.

Robert C. Martin described this decline in his 2000 paper "Design Principles and Design Patterns", and he named four symptoms. Each one is something a developer feels while working, not something a tool measures.

The four symptoms of design rot

Rigidity: A small change forces changes in many other places.; The euro change touched eleven files.
Fragility: A change breaks something that seems unrelated.; The refund screen broke although nobody edited it.
Immobility: A useful part cannot be reused elsewhere, because it drags its dependencies with it.; The price calculation cannot leave the checkout without the database.
Viscosity: The right change is harder to make than a hack, so people make the hack.; Adding one more if statement is quicker than fixing the design.

The symptoms often arrive together, and they feed each other. A rigid class gets edited in many places at once, which makes fragile breakage more likely. Fragility makes people afraid of careful changes, which raises viscosity, and every hack added under viscosity makes the next change more rigid.

Naming the symptom matters because each one points at a different cause. Rigidity and fragility usually mean one class is doing too many jobs or depends on too many details. Immobility means a part is tied to the concrete things around it. Viscosity means the design makes the correct route expensive. The five SOLID principles are each aimed at one or more of these causes.

← → move through sections and cards