Software Maintainability – Is Anyone Managing This?

As noted in an earlier post, “the act itself of maintaining software causes it to degrade.”  (Alain April, Software Maintenance Management)  The continual decline of software has also been noted in the Laws of Software Evolution, as conceived by Professor Meir Lehman.

Can anything be done about this?  Should anything be done?  Is it worth the cost and effort to keep software healthy and maintainable?  I don’t think the science of software maintenance has advanced enough yet to consistently provide the methods for answering those questions, but I was reading some interesting observations and thoughts in a paper entitled, Capturing Industrial Experiences of Software Maintenance Using Product Metrics, by Akito Monden et al.

The authors of this study examined a 20 year old COBOL system in Japan and the maintenance practices that had been followed to support it.  This organization had followed a practice of refactoring programs as they became more and more unmaintainable.  (Does anyone in this country employ such long range thinking?)  In general, once a program crossed a critical line of unmaintainability it was refactored.  A diagram of their practice was depicted as follows:

The IT organization that was managing their code base this way was obviously proactive about keeping their software maintainable.  They did not, however, have fixed guidelines about when a program should be refactored, but instead relied on the judgment of the programmers.

The authors of this study decided to determine if there were metrics that could be used to determine when the line of acceptable maintainability had been crossed in the past, according to the judgment of the past programmers.  Such events had resulted in refactoring.  They did their analysis by examining the history of refactorings and trying to correlate the timing of the refactoring with changes in the measurement of 20 different variables.  They found five variables that seemed to fit the pattern and could be used for future decision making about refactoring.  The variables were:

• Cyclomatic complexity – basically the number of possible paths through the program – this obviously increases complexity

 

• Number of variables per line of code – as variable density increases so does complexity

 

• Number of procedures/subroutines per line of code – the last three metrics all relate to increased complexity due to delocalization of function

 

• Number of external procedure calls per line of code

• Number of unique external procedure calls per line of code

Interestingly, they did not find that strictly measuring the lines of code count itself was a good indicator of degraded maintainability.

As a side note, I think what\’s also interesting here is that the authors basically ended up measuring what causes programmers to feel a program is too complex  – the five items noted above.

The authors claim that each of the metrics can be used to measure a program\’s maintainability.  I do not believe they are claiming they must all be used.

Implementing a practice of planned refactoring for maintainability is sensible if an organization is planning on retaining the software for some period of time.  I don\’t know that there is any proven means of calculating what that period of time is, but the concept is worth keeping in mind.