Back to raw metrics.

A customer wants you to audit the quality of an application or a portfolio of applications. He expects for an answer to a very precise question. For example:

• This application is an important part of my budget: is it possible to reduce its costs and how?
• I have been asekd to take the maintenance of this application. I only know that it is a complex application. What do I have to expect?
• Is it possible to outsource this application? What are the risks?
• We are going to merge with this entity. What systems should we use? Theirs or ours?

There are two different questions in these questions:

• What are the costs?
• What are the risks?

IT produces applications. IT delivers to users applications that allow them to realize the business of the company. If these applications break down, generate errors, work too slowly, lose data, the users are dissatisfied.

An audit of the quality of an application should always answer to this double question: how to optimize the costs without sacrificing the quality of the product?

Let’s begin with the quantitative metrics available with a code analysis tool.

The size of the application, in number of lines of code ( LOC), or its various modules. This measure is dependent on the technology: 200 000 lines of code (200 kLOC) is an important size for a J2EE application but relatively small for a Cobol one.

The number of objects. By object, I mean of course files, but also components: Java classes and methods, JSP pages, Javascript files, Cobol programs and paragraphs, SQL functions and procedures, etc. In itself, this number is not significant, but reported on lines of code, we obtain a very important measure: the granularity of objects.
200 kLOC in 200 classes Java represents 1 000 lines of code by class: it is enormous. This application is probably not very ‘legible’, and will require an effort – thus a cost – more important when we shall want to transfer it to another team. To take into account if our customer needs to do an outsourcing or will get the maintenance of the application.

The number of methods by class: the higher it is, the more the classes will be ‘heavy’ of features. It might indicate a problem of design, which is going to weight on the understanding of the application, but also on the difficulty to implement evolutions. The risk becomes higher to introduce defects when a developer makes a modification. Plan your tests accordingly. This is going to increase the costs of maintenance.

Also look at the number of LOC by method, again to measure the portability of the application. But especially, the percentage of comments (lines of comments / total LOC). These measures help to estimate the cost of transfer of the application.

The number of lines of code in comments. A developer puts off the code in comments to protect this version of the code. It indicates that he is not sure, either of the new feature to implement, or of the code to produce to implement this one.
It is generally a good indicator of the age of the application. The more you have code in comments, the more developers did succeed one another on the application, the older is the application. Once however, this rate of code in comments was high in a first release of an application, which indicated evolutions of the functional specifications in the course of the development phase.

Other interesting measures, when they are available: the empty comments. Or the objects with the whole code in comments: the program or the method does nothing. Except adding on the cost of maintenance pointlessly.

The number of duplicated lines. Very dangerous for the reliability of the application. If the same block of code is duplicated N times, any modification of this code must be made N times. Not only it raises the cost of maintenance of the application, but if the developer forgets to duplicate the modification on a single block, the risk of dysfunction for the users is raised. Thus the costs of an evolution and the cost of testing also. Rather than to duplicate a feature, it would be more sensible to have a unique component that implements this one. A reusable component, well developed and tested instead of N duplicated components: what do you prefer, for your budget and your users?

The cyclomatic complexity (CC). Without detailing this measure, let’s say that CC is a good indicator of the number of functional or technical rules in a component or an application. Beyond 60 000 points of CC, an application embarks so much features that it becomes very difficult to test. Plan to use (and train your teams on) a tool of automation of the tests, or you could explode your budget and your plannings.

Identify components with the highest CC to locate those who will be the most difficult to maintain. And verify if they are documented correctly or add this point to your tasklist.

We see that with a few raw metrics, we are able to answer the questions of our customer:

• What is the cost of transfer of this application? What is the effort for a new developer so that he is operational on this application?
• What is the cost of an evolution for this application? How to plan testing?
• What is the risk of introducing a defect when we realize an evolution? What is the risk of non-reliability for the users.

With some experience – these numbers may vary according to the technologies – but especially some simple common sense, we can quickly learn which are the interesting data and how to combine them to optimize these few measures.

A metrics is only a number. It is the use that we do with it that gives it all its value to answer our customers’s question: costs and risks?

This post is also available in Leer este articulo en castellano and Lire cet article en français.