The irony of maintainable code

Suppose there exists a lucid, performant, appropriately documented codebase with fluent interfaces, pithy names, succinct tests and coherent classes residing in cohesive modules loosely coupled with their neighbours. Is it maintainable? Very likely in theory, less so in practice.

Most often, this is simply because the maintainers are a different set of people than the creators. Also because of the way business finance works, maintenance is often the job of a less skilled set of people. Less skilled in the sense that they often have a problem with reading object oriented code. They are used to linear reading of procedural code and get disoriented by all the polymorphic jumping around. Ha! Speak of unintended consequences – object orientation leads to disorientation.

Less skilled also in the sense that they don’t appreciate unit tests as documentation, even when they attempt to read tests, they are put off by all the mocking. They don’t understand what the right granularity is for dependency injection and all the fuss over small classes and avoiding primitive obsession.

So they don’t add/fix tests along with bug fixes and enhancements. The builds turns red and remains red. Continuous integration is forgotten. Soon there is no automated way to check against regression. No one attempts even small scale refactoring. The codebase is now unmaintainable by any definition.