What we mean when we say a system is maintainable

"Maintainable" gets used as a synonym for "tidy" often enough that the two have started to blur together. Tidy code is pleasant to read. Maintainable code is something narrower and more useful: it is code the next engineer can change without fear, even when that change is one nobody anticipated when the code was written.

Maintainability is not tidy code. It is how cheaply the next person can make a change they were not expecting to make.

Those are not the same property. A codebase can be immaculately formatted and still be maintainable in name only, if every change requires understanding five other files first, or if the tests give false confidence because they mock away the part that actually breaks. Conversely, a slightly rougher codebase with clear boundaries and honest tests can be far cheaper to change safely.

The practices that actually move this number are unglamorous: small, reviewed increments instead of large unreviewed ones; boundaries drawn around the parts of the system that are likely to change, not just the parts that are architecturally convenient; and tests that exercise real behaviour rather than implementation detail. None of this is exotic. Most of it is just consistently applied.

We treat maintainability as a build-time decision, not a cleanup task scheduled for later. On a system that's already live, that's exactly when it's most expensive to add.