Schauderhaft

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.

5 Responses to “Developing for Maintainability”