Metrics For Identifying Software Development Problems (And Metrics to Avoid)

Reliable, actionable metrics are critical for identifying where the problems lie in your software development processes. Unfortunately, many organisations fail to use effective metrics during analysis. Using poor quality metrics may lead to unactionable data or worse, inspire changes that harm productivity rather than improve it.

This article will review the importance of using appropriate metrics during developer analysis. We’ll highlight why some of the most commonly used KPI metrics for software development might not provide accurate or relevant information to managers.

The Importance of Using the Right Metrics

By utilising high quality and actionable performance data, everyone benefits. Recruiting managers hiring new personnel will be able to highlight the skill gaps within an organisation, DevOps teams will have better information when trying to optimise workflows, and senior managers will have a clearer picture of software delivery performance. 

But what makes some metrics better than others? Key features to look out for include:

  • Reliable: Of all the potential flaws in bad metrics, the worst is for the data to be inconsistent or open to interpretation. Leaders must be able to trust that the metrics they receive are accurate — otherwise, any changes they make based on that data will be ineffective or harmful.
  • Objective: While team leaders might have a specific hypothesis while conducting developer analysis (i.e. a need to improve efficiency or quality of code), this should not influence the performance data. The best way to ensure objective data is to automate your analysis, as a digital solution removes the risk of bias. 
  • Actionable: Some metrics produce data that is interesting but difficult to implement effectively. Leaders seeking to optimise workflows must utilise metrics that can help make real, concrete changes to the way a software development team works. 

Without the correct metrics, team leaders and managers will struggle to get an accurate picture of the software development problems blocking their team’s productivity.

Metrics to Avoid When Identifying Software Development Problems

1. Counting Lines of Code

Counting lines of code (also known as LOC or SLOC) is one of the oldest KPI metrics for software development, but it’s also one of the most flawed.

The sole advantage of LOC as a metric is that it’s simple and easily automated. However, the metric offers no strategic value. LOC very clearly indicates how much work a developer has done in a specific period, but it has no way of measuring quality. It’s also very limited as it’s only able to show how many lines were added, not the amount of effort needed to make those changes. Furthermore, the metric is rarely applicable across different programming languages.

If your team’s only problem is that some members are not contributing, this metric will quickly indicate where the problem lies. However, if you want to identify the intellectual effort that’s gone into making a change or to manage technical debt, LOC will be of little help. 

2. Function Points

The point of any system is to complete a specific task, so by dividing a project based on the different functions required to complete the specific task (or “Function Points”), team leaders can identify what parts of the development process are causing problems.

However, purely using Function Points won’t account for the time or resources necessary to complete a particular function. So although it might take your team much longer to design a certain feature, this is not an indication of poor efficiency; it may simply be that it is a large and complex function.

In addition, the team leader must define function points themselves. Dividing a project in this way can take a lot of time and effort, and the involvement of human beings means the data is in danger of being subjective.

3. Sprint Burndown Chart

A Sprint Burndown Chart compares the remaining workload to the time left to finish the entire project. They allow managers to quickly work out the team’s progress on both the overall project and the current stage of development.

However, the charts are not without their disadvantages. Using this metric often distracts teams from the problems with their ways of working, as a sprint burndown chart demands significant focus on organising and improving the chart itself.

4. Code Churn

Managers can measure any code that is rewritten or deleted shortly after being written with a metric known as code churn.

It’s a helpful tool for managers to consider when making staffing decisions. While some code churn is normal, seeing a high churn rate from specific developers might mean that those developers are unsuited to their current projects.

The problem with using code churn as a metric to identify problems is that there’s no way to accurately say what causes the code churn in the first place. While managers can discuss with a particular developer why they have a high churn rate, doing so risks a high level of subjectivity. 

A More Effective Metric For Identifying Software Development Problems

Unless a manager uses and collates a range of different metrics, they’re unlikely to get a full understanding of how their team works and what software development problems may emerge.

However, using different metrics can be complicated and time-consuming, especially if done manually. As a more efficient alternative, BlueOptima’s digital solutions utilise a metric we call ACE, or Actual Coding Effort.

ACE combines up to 36 separate metrics to define developer productivity as accurately as possible. You can broadly categorise these metrics into Volume (how much code a developer creates), Complexity (how difficult the code was to create), and Interrelatedness (whether the different projects a developer is working on are related).  

Coding Effort provides a more meaningful foundation to base decisions on because of the accuracy and detail it provides to managers. The metric allows companies to compare various teams and individuals fairly in terms of cost-efficiency, as it comes from a reliable and objective source: the Developer Analytics tool.

Expand Your Team’s Potential with BlueOptima

Our Developer Analytics tool combines the Coding Effort metric with an analysis of code quality to provide leaders with a complete understanding of their team’s output. Using the data provided by the tool, managers can make their development teams vastly more efficient and identify any software development problems quickly. 

Contact us today to discover how BlueOptima’s Developer Analytics tool can help your company succeed. 

Case Study - Implementing an Agile Transformation

How one of Europe’s largest Universal Banks turned a challenging Agile transformation into a successful one.

Measuring the impacts of 'The Great Resignation'

How has the 'Great Resignation' impacted your efficiency? Resignation rates are at an all time high currently and the impact this has on developer productivity can be devastating.