Just as Supportability, Maintainability is one of these Non Functional Requirements, that is or should be required from every software development project. So what does that mean? Wikipedia defines it as
the ease with which a software product can be modified in order to:
- correct defects
- meet new requirements
- make future maintenance easier, or
- cope with a changed environment;
Wow, that's great. Because it lends itself for an 'easy' test for maintainability. Take the completed product, make up some new requirements and measure how long it takes to implement those. If you do this with different products for same task, you can compare the time needed, thus comparing maintainability. Unfortunately most of the time, the requirement is stated before any software is written. And only one piece of software gets written, so there is nothing to compare to. So what to do?
Since one can't realistically measure maintainability we once more should concentrate on characteristics making software easier to maintain, i.e. easier to change. There are plenty of measures around that are thought to be linked to maintainability. Cyclomatic Complexity being possibly the best known. I personally prefer toxicity, which is based on Cyclomatic Complexity and a couple of other measures, which contribute to the toxicity with the amount they are above a certain threshold:
Metric Level Threshold
File Length file 500
Class Fan-Out Complexity class 30
Class Data Abstraction Coupling class 10
Anon Inner Length inner class 35
Method Length method 30
Parameter Number method 6
Cyclomatic Complexity method 10
Nested If Depth statement 3
Nested Try Depth statement 2
Boolean Expression Complexity statement 3
Missing Switch Default statement 1
Compared to a single simple measure, this has the benefit of being less prone to optimization for the measurement, although of course this is still possible.
So does a low, even zero toxicity guarantee maintainable code? Hell no. For starters there are a couple of different things to consider:
- Is the code well covered with tests?
- Are the current requirements specified in a suitable manner (e.g. using tests)?
- Is the code written in a consistent style
- Is all the code including the documentation under control of a version control system?
- Is the structure of the application, its architecture defined and documented?
- Is there an automatic process for building new versions of the software (i.e. ant, maven, make scripts or similar)?
- Is the code written in a language that is well known and understood and which has a large user community?
Everything but the last bullet point is pretty much identical with what I consider base practices for any serious software developer.
So I propose: The next time you encounter the vague requirement of maintainability, replace itybe useful and well testable requirements, based on specific practices and metrics. It still won't guarantee maintainability. But it will increase the chance for it.
Wan't to meet me in person to tell me how stupid I am? You can find me at the following events:
- Spring Data JDBC - New Kid on the block.
- Softwaredevelopment in the 21st century.
- Domain Driven Design mit Relationalen Datenbanken und Spring Data JDBC.
- Kerbal Space Program, Glücksspiel und Psychologie und was das mit dem (Berufs)leben zu tun hat.
- Javaland Freeletics
- Domain Driven Design mit relationalen Datenbanken und Spring Data JDBC
- The New Kid on the Block: Spring Data JDBC