Maintain Ability

Maintainability should subsume various properties defining InternalQuality :

because the final reason for a software product to hold these properties is the cost of maintenance.

Personally I like the term because when speaking about quality, I always had to distinguish things :

ExternalQuality is quality of the product, as the people using the software can define it (grosso modo). InternalQuality is quality of the design, as defined by the technical people making the software. When ExternalQuality is high, the customers are happy (nearly tautologic definition). When InternalQuality is high developers are happy, and keeping the customers happy is less expensive. And so on.

Now I just use "Quality" when speaking about properties the user or customer requires for the software product, and MaintainAbility for all the internal properties that facilitate the production and maintenance of the software product. --ChristopheThibaut

Are there any metrics for maintainability that can be derived from the code?

And if there are, how much are they subject to Heisenberg problems (e.g. the HeisenbergUncertaintyPrinciple)? If you measure maintainability metrics, will you get higher metrics, but code that's still as unmaintainable or worse?

In CodeComplete, SteveMcConnell lists the following metrics for maintainability:

The SEI has published a Maintainability Index Technique for Measuring Program Maintainability: http://www.sei.cmu.edu/str/descriptions/mitmpm.html. It is based on:

See HowToWriteUnmaintainableCode.

Personally, I am very intrigued by the relationship between coupling and maintainability. Many authors have claimed that high cohesion and low coupling is the way to go, yet I believe that a linear relationship between coupling and maintainability just don't seem to make sence. Under such an assumption, less coupling is better. However, everyone will agree that striving for no coupling at all is the ultimate guideline for creating GodClass -es, which are not exactly ideals w.r.t. maintainability.

Of course, this relationship depends on how you define coupling. I would suggest to consider coupling as the number of collaborations you need to implement a semantically related set of requirements. Under that definition, having no coupling truly leads to GodClass -es, and having maximum coupling would lead to heavily coupled tool classes which all are responsible for only a very minor detail in the stated set of requirements. This relates to DesignPatterns in that they propose a degree of collaboration (and therefore coupling) which distributes responsibilities evenly over a number of classes. Maybe DesignPatterns can be used as the optimal degree of coupling, from which deviations (to both the GodClass -es and overly distributed responsibilities extremes) would have negative effect on maintainability.

Such a relationship between coupling and maintainability could be visualized as a U-shaped curve in a 2-dimensional space with a Y-axis for maintenance effort and a X-axis for coupling. This model, of course, is totally hypothetical, but seems - at least from my experience - to be more realistic than a linear relationship. -- Bart Du Bois

Many authors have claimed that high cohesion and low coupling is the way to go, yet I believe that a linear relationship between coupling and maintainability just don't seem to make sence.

Your confusion seems to stem from trying to force the maintainability to be a function of only the coupling. What those authors usually mean is that if you hold everything else constant, lower coupling and higher cohesion reduces maintenance costs. This would mean that the number and size of the classes must remain constant while you change the coupling and cohesion. Pushing the coupling so low that it forces other variables to change (i.e. class size) is outside of their claims.

Another hypothetical model: maintenance_effort = K1 * coupling_metric + K2 * (sum of squares of class sizes) (+ some other factors, which we can ignore for now). This explains your visualized U-shaped curve and maintains the linear relationship between coupling and maintenance.

Or, another alternative, which could be applied (recursively) to anything made up of smaller parts: maintenance_effort = K1 * coupling_between_parts + sum of maintenance_effort for all parts. For a program, the parts could be global objects and classes. For a class, methods and members. For a method, parameters, statements, and expressions. For an expression, operands and operators.

Your confusion seems to stem from trying to force the maintainability to be a function of only the coupling.

You are right. Moreover, your hypothetical model outline is quite interesting, e.g. to explain preference for a decomposition strategy. Are you aware of any references or known usage? -- Bart Du Bois

No, I just made it up while editing the page. It seems to fit my experience. For example, the tendency for non-OO functions to be longer than OO methods. The classes provide an additional layer of decomposition that can be taken advantage of to limit interactions between program parts, and effectively reduce the possible coupling.

EditText of this page (last edited February 8, 2006) or FindPage with title or text search