If you’re having trouble bringing new features to market, it might be time to start a development quality program. Innovation and growth are dependent on code quality. Two hallmarks of success for DevOps teams are how quickly new features go to market and how often new features fail. Our 2022 observability report shows a strong correlation between full-stack observability, fewer outages, a faster MTTD, and a faster MTTR.

Here are four steps to better code quality.   

1. Track your quality metrics.      

Four key performance indicators (KPIs) help measure the quality of submitted code. These KPIs help you identify the sources of code defects and areas that require the greatest developer effort.  

  • Build success: This measures the number of times new code is successfully compiled or integrated into the overall application. You’re aiming for as close to 100% as possible. 
  • Unit test success: This is the percentage of unit tests your new code passes. The goal is to make this as high as possible.
  • Code coverage: This is the amount of your application's code base that's subject to at least one unit test. Aim for 100% code coverage.
  • Defect volume: The number of defects introduced into an application by a specific module of code. This number should be as low as possible.

2. Measure code velocity.      

How fast is new code written and committed in your organization? Tracking code commit volume shows whether your development velocity is affecting code quality. Correlate defect volume with code commit volume to identify the optimal balance between velocity and stability.

3. Build development-quality dashboards.      

Identify the technology that supports your development processes, such as source code repositories and build/test automation platforms. Then use your development toolchain's APIs to extract quality and velocity data and send them to New Relic using the custom events API. Find sample DevQual dashboards in the New Relic OMA resource center on GitHub, such as this bottom-of-the-funnel analysis dashboard.

4. Baseline. Improve. Wash, rinse, repeat.  

When you’ve got data flowing into your development quality dashboards, it’s time to establish a baseline. This could be from two to six weeks of data, depending on your current development pace. One way to do this is to align baseline collection and evaluation with your sprints. 

After you have your baseline, identify which areas need the most improvement. For example, if your defect volume is high, identify the specific source of new defects by tracking attributes such as timestamp, application, and code module. Now your engineering team can focus its efforts on improving those code modules that generate the most defects.