How software metrics improve software development?

A software metric is a measure of software characteristics. Software metrics are valuable for many reasons such as:

• measuring software performance
• planning work iterations
• measuring productivity and different use cases.

In the software development process, many metrics are correlated. Software metrics are similar to the four functions of management:

• Planning
• Organization
• Control
• Improvement.

I’d like to describe shortly this difficult subject with one sentence:

“We have to use metrics to create high-quality software and develop our skills.”

Marcin Bielak

The more we know about our code, the better product we create, and the more hidden bugs we avoid.

Software metrics can be classified into two groups – product metrics and process metrics. We’ll take a closer look at each both below.

Product Metrics

A product metric, according to its name, measures a characteristic of a software product. What can we measure? For instance, size, complexity, quality, or reliability of software.

1) Size and complexity of software

As developers, we spend a lot of time writing code. But we spend even more time maintaining that code. So we need to understand our products. Where we look at the complexity and quantity of our modules we can see the real state of the art. Software design complexity is difficult to assess without using complexity metrics and measures. Let us see three important ones:

• Halstead’s Complexity Measures
• Cyclomatic Complexity Measures
• Function point

2) Quality and reliability of software

If our software has many unresolved flows or bugs we can be sure that both its quality and reliability are low. It shows at the moment we decide to ask our users for their opinion. I bet you’ve seen it many times before – people tend to keep positive reviews for themselves and share the negative ones online. Developers should keep their eyes on the reviews to make sure customers can rely on the product and use it to eliminate annoying and tedious tasks the software is meant for.

There are two main approaches to software quality: defect management and quality attributes. A software defect can be regarded as any failure to address end-user requirements. Common defects include missed or misunderstood requirements and errors in design, functional logic, data relationships, process timing, validity checking, and coding errors. This approach to software quality is best exemplified by fixed quality models, such as ISO/IEC 25010:2011. This standard describes a hierarchy of eight quality characteristics, each composed of sub-characteristics.

Software reliability is defined as:

“The probability of failure-free software operation for a specified period of time in a specified environment.“

Carnegie Mellon University article

Optimistically, we might think that once our piece of software has run correctly, it would do so forever. As much as it’s true on workstations, production machines are not as merciful. Software reliability on the production machine depends on many cases: environment, geolocation, climate, power quality, and more. So if our test cases in automatic test scenarios were developed with a focus on quality and reliability we probably can see expected product success.

Process Metrics

You probably have guessed that process metrics measure the software development process. For example, the efficiency of fault detection. They are used to measure the characteristics of methods, techniques, and tools that are used for developing software.

Our recommendation in the software development process is automatic verification and automatic deployment ( CI / CD ) for every change with a few important metrics:

1) Security fixes for dependent libraries and frameworks

We are still reusing Open Source libraries considered by some risky because of the lack of commercial support. I believe that the support from engineers around the world makes open source more maintainable than commercial projects. Regarding security, the flaws of using Open Source can be reduced by using proper tools and taking precautions. OWASP, for example, declares a fair share of best practices and suggests useful tools to keep the desired security level of our software. Of course, we also use a tool called dependabot that automatically creates pull requests and estimates the percentage of features that should work in the new version of the code. It’s good practice to verify if the requirements of our code are up to date.

2) Static analysis in Continuous Integration (CI) flow

All CI flows in our code base are based on Sonar tool and we can understand what is going on in our code changes. Of course, the best view about code quality is code coverage. Our development team understands the risk of using external modules and packages – you take them for free but with a share of the uncertainty of how they work. Dealing with documentation and open source packages give our team the impulse to develop our tech skills on a regular basis.

3) Code coverage and code complexity

Our DevOps team contributes to and reviews its own code metrics on a daily basis. Developers know which modules are the most valuable and important to our clients, which makes them put more stress and focus on the quality of those particular parts of the software.
What’s more, the discussions about potential risks are a significant part of our work.

Minimum 50% of code coverage on branches, lines, function, and classes give us quite a clear situation in quality.
In practice, a regular and non-critical application with no code coverage shows the highest increase in quality up to 50% of coverage. From that point, raising the bar is more of a matter of improving the team’s skills than significantly improving the tests. That’s why one of the requirements for our codebase is to maintain at least 50% of code coverage (more in the critical parts of the application).

Code review for skills improvements

A very important phase of our development cycles is a code review and feedback collection from other DevOps.
With a fresh view of our code, we can fuller identify and address risks, introduce innovations, propose new features, and much more.
At Grandmetric we are still improving our skills in Agile methodologies for best quality software development.
Regular collection and analysis of code metrics give us a solid set of information regarding our software health as well as qualitative feedback from the software development process.