A code quality control process must not be solely based on automated tools, rather it should combine tool-based analysis with a certain amount of human interaction. There are endless variations of how a code quality control process can be implemented. In this blog-post I’d like to give a few insights on how regular code assessments, named here monthly assessments, can lead to a feedback loop that improves the code quality control process.

The Code Development Process and the Code Quality Control Process

Variations to code quality control processes were discussed, for example, in an earlier blog post from Martin on the evolution of quality processes. In this blog article, I will use as illustration the code development and the code quality control processes concisely described in text as follows.

• [Roles involved in the code development process. Actions.] The code development process has as main actors the roles Developer (DEV) and Project Manager (PM): a Developer implements a system according to a task list, whereas a Project Manager schedules the task list.
• [Additional role involved in the code quality control process. Actions.] The code quality control process has as main actors the previous two roles, Developer and Project Manager, and in addition a Quality Engineer (TQE) role: the Quality Engineer interprets a dashboard summarizing metrics computed by automated tools, adds code quality tasks to the task list and creates a quality report; the Project Manager interprets the quality report and schedules the additional tasks accordingly.

The two processes described above can be visualized using a diagram like the one from a research paper authored by my colleagues at CQSE and Munich RE. This diagram is included for reference below.

Implementation of a Code Quality Control Process

When a code quality control process is attached to the code development process, a number of parameters of the process are discussed among the roles involved in development:

• The scope of the code quality control process: is only the backend code from a project relevant, or should a scope be used that includes both backend and frontend code?
• Quality goal: the goal is formalized as a strategy defining which findings from automated tools are subject to being fixed during the regular code development activities. For example, a so-called preserving strategy determines that new findings should be addressed, while an improving strategy determines that not only new findings, but also existing findings in modified code should be fixed during the regular code development activities.
• A third discussion point revolves around the frequency of quality reports, e.g., one report per development sprint, or rather a less frequent strategy, where a quality report summarizes development once every 6 or 12 months of development.
• A last discussion point used for illustrating this blog post is how to react to changes in the code development process. There are regular updates to the coding guidelines documents that should be considered, or the addition of a code review component to the code development process.

Typically we aim to address all these discussion points with one meeting that is scheduled when the code quality control process is started. However, we found that over a long period of time the parameters are updated more or less ad-hoc and not all roles from the project are kept up-to-date with the reasoning behind these changes.

Regular Feedback Meeting

• In order to assess how the code development and the code quality control processes interact, we use a regular meeting whose main purpose is to assess whether the quality goal has been met or missed during the development of a system. This meeting typically involves two roles, namely the project manager and the quality engineer responsible for the application.
• The quality engineer interprets a dashboard summarizing metrics computed by automated tools and provides traffic-light-based assessment of how the development team works with respect to quality goal relevant findings. The meaning of a green/yellow/red assessment is project specific. (Typically a green color is used to denote no significant findings left unaddressed, a red color is used to denote some significant problems left unaddressed, whereas a yellow assessment names specific classes of findings that have not been addressed up to this point, however do not accumulate to a significant technical debt for the subsequent development iterations.)
• The regular feedback meeting serves practically to re-assess whether the parameters of the code quality control process are still well synchronized with the evolution of the codebase and of the development team. In particular, such a meeting serves to answer questions like the following. 1) Is the quality goal strategy still appropriate? 2) Should a quality report and a detailed analysis be promptly scheduled? 3) Should additional performance indicators be configured for the automated tools, for example handling a longer than usual migration of an obsolete technology.

Summary

While there are many variations of how a code quality control process is implemented, we found that for applications with a long lifespan expectancy, it is worth to regularly assess the development activities. The choice for frequency of regular assessments is monthly: a monthly assessment summarizes the development over the last month and facilitates a discussion of suboptimal points at managerial level.

Feel free to share your opinions by commenting on this article: I’d be very interested to know how often the code quality is assessed for your development projects and which roles are involved in the review phase.