In the previous post Measure and Control, I said that quantitative metrics such as the number of lines of code (LOC) or the measure of cyclomatic complexity (CC) were:

• easily available – in every software of code analysis ;
• exact – these measures do not vary (too much) depending of these tools ;
• easily understandable for the management.

Does this mean that qualitative measures would be difficult, inaccurate and poorly useful? In fact, everything depends of what you want to do, thus of the use case. Today, let’s see an ideal use case: Continuous Improvement.

Elect 12 or 15 rules considered as critical and for which you – your project team – aim at zero defects. Every night (or every end of week) the code of the application is analyzed and the violations for this critical metrics are identified. Every morning (or every beginning of week) the team of project reviews the recently introduced defects and decides on its remediations. If the code analysis software is plugged in the development tool, these remediations will appear in every developer’s task list. You can find an example of such a process here: Effective Code Review with Sonar.

Which are the benefits of a process of continuous improvement:

• Lowest cost of correction of non-quality, because as soon as possible in the development cycle. Sooner is cheaper.
• Continuous improvement of skills: the project team gets acquainted with the most important good practices.
• Controlled technical debt: the drifts of maintainability are contained.

However, in order to reduce the additional workload (analysis of the source code, review of the results, distribution of the corrections), it is recommended to have an adequate equipment:

• A version management software allowing to share the source code between developers and to supply it to the code analysis tool.
• If possible, a software to manage the tests to validate every release (build).
• An integration tool to automate the tasks of compilation (build), code analysis and test.

Ideally, these tools must be able to communicate between them, in particular to:

• Upload testing results in the code analysis software and identify, for example, the components ‘most dangerous’ for the application: components with a high or very high cyclomatic complexity that are insufficiently tested. Because they are complex, these components present a high risk of introducing a defect in case of an evolution, and thus must be prioritarily tested.
• Download the list of the corrections to be done into the development tool, for every developer.

We are talking about a complete process of continuous integration, which supposes completely integrated tools but also a sufficient level of maturity of the development team. The integration is important to automate the various phases of the process and reduce the additional workload for developers, and thus to facilitate the acceptance of this new mode of work.

I would also recommend to begin with a limited number of metrics, to avoid submerging the developers with good practices and zero tolerance. It will be possible to widen the target afterward, when developers will have climbed this first step and will completely master this new organization. Thus the importance to use completely integrated tools.

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