Software quality: From metrics to habits

Software quality: From metrics to habits

Whatever the field or project size, software quality management – from metrics to processes – is a cornerstone of today’s software development. 

An overview by Flavien Huynh.

Software quality metrics

There is more to software quality than preventing bugs. It also gives us the opportunity to reach better code. From the different levels of quality to the various incentive to evaluate quality, there are many paths to software quality.

It is not recent news: there are many examples in software development history where a better focus on quality would have prevented real-life failures. Learning from past errors, the development industry has gradually integrated software quality into its vocabulary.

This evolution hasn’t always been smooth and unanimous, because software development has a specificity. From the outside, a software product operates as expected, but still contains internal defects (bugs) that might eventually show up when certain conditions are met. The hunt for bugs has been (and still is) a strong driving force behind software quality research and activities.

Software quality levels

From the starting days of software quality some decades ago, when the quality of the software was met as soon as it ran without crashing, a lot has been discovered and proposed.

Firstly, software projects became more complex and connected to an ever-growing number of software layers. These layers are in turn developed using the same principle, producing a rich and intricate combination.
Second, software quality assessment has also been growing, including new concepts, techniques, regrouping them in standardized recommendations.

Level 1: Software quality metrics

Software quality metrics basics
Software quality metrics basics “Use project data”

The first and most straightforward way to assess quality is by way of quality metrics.
In essence, these are project measurements, coming straight from analysis tools run on the source code. Static or dynamic code analyzers, programming rule checkers, or test coverage solutions. These tools generate precise information for each function or file in the project and are used to great benefit.

Then all you have to do is parse these tools logs or dashboards and verify that metrics meet expected thresholds.
It is quite easy to put into practice but can become a daunting task for big projects. Tens of thousands of lines of code may produce huge quantities of metrics.

Background information

Level 2: Software quality model

Software quality model
Software quality model “Deduce knowledge”

A quality model’s primary function is to provide high-level quality indicators, which computation is based on quality metrics. This means these indicators translate quality good practices into approved and reliable computations. So, a good quality indicator will help detect what piece of code needs attention, without having to parse all metrics in search of an outlier.

The knowledge produced by a software quality model has a higher level of abstraction. Its goal is to help understand what these metrics actually mean. But you still have to work out what to do and ask yourself “Is this 9% comment rate OK?

Background information

Level 3: Software quality scorecard

Software quality scorecard
Software quality scorecard “Take informed decisions”

The quality scorecard is like the expert’s final rating after a thorough analysis. If you trust the expert, that rating gives you an assessment of the code quality as a whole. But a scorecard shouldn’t only qualify the tip of the software project, it has to qualify each and every file, class, function. And speaking of trust, the scorecard is fully based on the software quality model results, which is itself an implementation of good quality practices.

The power of a quality scorecard is that it provides a synthesized vision of the project, checking if it’s in good health quality-wise. Also, it allows fast detection of pieces of code needing attention because of a bad or deteriorating rating.

Background information

Software quality incentives

We saw that the motivation behind software quality is not just about the bugs anymore, but better quality for the code. Beyond that noble intention, quality is also an expected result of the software production chain. And that expectation doesn’t stop at the development team. Several levels of stakeholders can require specific quality levels to validate a software product.

As a consequence, software quality has to be followed, monitored, reported, and justified. This can seem like a lot of work, but it doesn’t have to.

Level 4: Quality management

Software quality management
Software quality management “Communicate quality”

Quality is also in the eye of the beholder. From the perspectives of the development team, project manager, company, or external client, code quality is different things. From precise function-level test coverage to standard compliance, maturity level or industry-specific indicators, all these quality attributes need to be part of a quality project and managed like any other project.

Whatever the level (metrics, model or scorecard), software quality management answers to a need to follow and communicate the current state of a project’s quality to parties that are not necessarily involved in the project daily lifecycle.
This is a sensitive task, which can miss the objective if it produces too large, highly detailed reports.

Background information

Level 5: Quality gates

Software quality gates
Software quality gates “Share a common quality objective”

We can see software quality as an agreement between two parties, and quickly visualize examples. The project manager checks that programming guidelines are followed by the development team, and then verifies the standard compliance. The auditor has a checklist of indicators to validate. The client needs to know if the project quality requirements are met.

Software quality gates handle all these cases, as specific verifications on the project quality assessment. It doesn’t replace or cancel a regular quality report, but it acts as a checkpoint (hence the name ‘gate’) to quickly answer the question “Is the project fulfilling the agreement?”. Of course, the agreement must be defined from the beginning, but that’s also what the quality gate is for. To share from the start what is being checked.

Background information

On the top: Quality in the process

Software quality in the process
Software quality in the process “Build software quality into a habit”

Software quality can be costly, if teams are mobilized each time a quality audit takes place, or if the process sets quality assessments phases before each release. Quality reports will be produced, gates will be crossed, but the price might be loss of motivation and distrust of the benefits of software quality management.

There is no “Reach Quality Now” button, but introducing quality practices in the development process, sustaining quality awareness by regularly communicating quality assessment is a good way to reach a built-in quality scenario.
As with all changes, trust in the results and smooth transition is the key to adoption.

Background information

Conclusion

Whatever the quality level or incentive combination, software quality is as important as the actual software product. It determines how well it will evolve, how heavy maintenance will be, or simply if it will be accepted or refused.
This is especially true in a continuous delivery scenario: quality takes the center stage as a means to simplify assessment and streamline validation.

Software quality metrics in practical examples

Hey there!

Subscribe and get a monthly digest of our newest quality pieces to your inbox.