Software maintainability. The ‘Poor Cousin’ in the Technical Quality Family

Posted by Luis Rodríguez on Jun 21, 2012 in CTO Corner, Maintainability | 0 comments

Code is usually not designed for change. Thus, while code meets its operational specification, for maintenance purposes it is poorly designed and documented. Symptoms are well known: understanding code that needs to be changed is hard, testing is too difficult and takes excessive time and resources, too many regression defects after simple functional changes or refactoring (it is difficult to reliably implement changes). You suffer from this, wouldn’t you?

According to Capers Jones, 7% of the total functional size changes every year, as an average. So (evolutionary) changes in installed software is the norm, and maintenance costs sky-rocket when maintainability degrades.

Why is software maintainability so bad (in general)?

High-level objectives, like “software should be easy to maintain” are never taken seriously. Other statements are equally too vague: “The Thing should be easy to maintain through proper object-oriented design and state-of-the-art tools”. Software development teams ignore them, even when a Software Architect is added to the team.

The problem with maintainability is to convert desires into realities. A proper framework for maintainability is needed, based on a few principles like the following:

1. Awareness first, then design for maintainability.
   If the development team discards maintainability as an ‘unnecessary luxury’, if they do not have skills to design software for the proper maintainability level, nothing will work later.
2. Maintainability is a multi-facet thing.
   Maintainability has multiple characteristics (in ISO-9126 parlance, analizability, changeability, stability and testability), and act both as constraints (“change will be possible”) and desired target levels (“change will be easier and cheaper”).
3. Maintainability has trade-offs that need to be accounted for.
   Think on software life expectancy (remember, some software systems seem to live forever, while others are “legacy-dead” before first released). Remember that design for maintainability costs money and effort/time (you need to estimate the payoff, which is extremely difficult, to decide the level of maintainability you can afford). Design for maintainability must compete for limited resources, and skilled developers for maintainability are rare gems.

If you don’t have a decent model for maintainability, including how much it costs and how much it pays, the whole action plan for maintainability is only “good intention”, not engineering.

Models for measuring maintainability in existing software

Any model that measures intrinsically how maintainable software is needs to take into consideration all the sources of maintainability defects: Excessive code duplication, excessive size or complexity in software units for the given technology, excessive coupling and too low cohesion (which typically indicate bad design), improper components naming and organization, lack of documentation, lack of (automated when possible) regression testsuites… These issues need to be detected in software artifacts, and particularly in source code.

Certain models (like the SEI Maintainability Index) are too simple to provide good answers. But there are models simple enough to be easy to use and understand, providing precise measurements of this quality characteristic. The Software Improvement Group (SIG) defined an intrinsic model for measuring maintainability in existing software systems, using a few code metrics (volume, complexity and size per unit, unit testing coverage, and duplication).

This model has benefits, when compared with other models:

• Use well-known, simple code metrics (LOC, Cyclomatic Complexity, etc.), ease to measure.
• Maintainability is broken down into their components, allowing root-cause analysis.
• Model is insensitive to format changes that do not modify maintainability. Volume influences complexity, but also intrinsic characteristics (“how is the software”) are considered, so mere volume does not dominate the results.
• It is largely technology-independent (implementation language, environment).

At Optimyth Software we have enhanced the base SIG model to take into account some factors not present in the original model:

• Coupling and cohesion are important factors that affect changeability, stability and testability.
• Code documentation is considered in the analizability sub-characteristic. Code comments help maintenance teams to better understand what is the particular purpose and what design constraints were observed in implementation elements.
• Provide specific recommendations that could be followed in preventive maintenance for better maintainability, reducing future maintenance costs.

Our SIG-modified model maps software properties to ISO-9126 maintainability characteristics as follows:

So, what can you do to help the ‘poor cousin’ of the technical quality and develop maintainable software? The answer, in my next article.

Stay tuned!