"Maintainable code" does not mean the same thing to a DBA as it does to a developer. Production Support staff will want something altogether different from either. These differing perspectives on maintainability have always been a cause of immense grief to IT projects.
To a developer, maintainable code simply means "code that is easy to modify or extend". At the heart of maintainability is carefully constructed code that is easy to read; code that is easy to dissect in order to locate the particular component relating to a given change request; code that is then easy to modify without the risk of starting a chain reaction of breakages in dependant modules.
Aside from "common sense" principles such as keeping code as simple and terse as possible, creating effective documentation, using source control, and so on, developers aim to ensure a clean separation of functionality in their code, with high cohesion and low coupling. They will generally employ a range of tools and techniques, such as MVC patterns, object-relational mapping tools, and test-driven development, which offer the promise of more maintainable code.
Unfortunately, such tools mean little to the DBA. They will find little solace in the idea that the code is elegant and object-oriented; it matters little to them if there are few inter-class dependencies. They are not enamoured by object-relational mapping. Maintainable code to a DBA means code that is written to a defined interface, based on routines, so that access rights can be restricted for security, and the SQL can be optimised independently of the application code. It is code that is instrumented and easy to troubleshoot, where any anomalous conditions within the application are logged, even if they don't cause errors.
Support staff will be largely unimpressed by either definition of maintainability. For them, a maintainable application provides an easily-accessible list of all possible 'exceptions', along with a description of what to do to fix the problem. They want an application that alerts them when there is anything that needs to be corrected, and gives them a step-by-step procedure to do so, or indicates who they should contact. They just want something they can keep upright, no matter what elegant innards lie behind and beyond the 'application unavailable: please contact your administrator' message.
What is the way out of this conundrum? Is it possible to reach a "consensus" definition of maintainability, or do we simply need to maintain distinct definitions and make it clearer which "type" of maintainability we're referring to?
As always, we'd all love to hear what you think. The best contribution to the debate, added as a comment to the editorial blog, will receive a $50 Amazon voucher.
Cheers,
Tony.