Customers experience code quality through the speed of the next change

Martin Fowler distinguishes visible quality—interface behavior and reliability—from the organization of the code underneath. A customer cannot normally tell whether two equally functional applications have tidy or tangled internals.

That seems to make internal quality an optional expense. The problem appears when either application needs to change. Developers must first understand the existing flow, find the correct place to intervene, and avoid disturbing unrelated behavior. Accumulated confusion makes each addition more expensive.

Fowler’s argument is that maintaining internal quality supports delivery speed rather than merely competing with it. Refactoring is part of keeping the system economical to modify, not a separate aesthetic pursuit.

The claim should not be turned into permission for unlimited architecture work. Its mechanism depends on changes the team will actually need to make. The useful management question becomes whether today’s shortcut reduces total effort or simply transfers work into every subsequent feature.