Code Climate Guest Post: Boost Engineering Speed With Objective Data

The following is a guest post from our partners at Code Climate—a leading Engineering Intelligence platform which helps software engineering organizations achieve excellence with data-driven insights.

Speed is critical in engineering — the faster you ship software, the shorter your feedback loops, and the greater your ability to iterate, innovate, and stay ahead of the competition. Yet as the saying goes, you can’t improve what you don’t measure, and engineering organizations looking to boost their speed will quickly see the flaws in engineering’s classic attempts at measurement. The subjective nature of metrics like t-shirt sizes and story points hinders teams’ ability to make meaningful comparisons across projects or track trends over time. To truly measure progress and improve over time, engineering teams need objective data like that found in Code Climate’s Engineering Intelligence platform, Velocity. 

Cycle Time as a Proxy for Engineering Speed 

At Code Climate, we recommend that engineering leaders evaluate engineering speed with code Cycle Time, a measurement of the time between a developer’s first commit in a pull request (PR) to when it’s ultimately deployed. This metric allows you to isolate coding activities from planning and design, and focus on the engineering-owned portion of the software development pipeline. Having an objective metric like Cycle Time makes it possible to determine whether your team is moving faster or slower than usual, and act accordingly. 

When they’re moving quickly, your team can take stock of what’s working and use that information to help shape best practices. When there’s a slowdown, you can work with your team to determine the cause and uncover possible opportunities for optimization.

The Four Components of Cycle Time

Cycle Time is a helpful metric for spotting trends in speed, but it’s not diagnostic. In order to determine why your team is moving at a given speed, you’ll need to dig a bit deeper. Make this easier by breaking Cycle Time into four parts, each one representing a portion of the software development pipeline:

• Time to Open - The time between the first commit in a PR and when that PR is opened. 
  
• Time to First Review - The time between when a PR is opened and when it is picked up for review.
  
• Time to Approve - The time between the first review on a PR and when it’s approved (this encompasses the Code Review process).
  
• Time to Deploy - The time it takes to deploy a PR after it’s approved. 

Each component has its own related metrics, which can help you narrow down your investigation even further. 

When working with metrics, it’s important to remember that quantitative data must always be contextualized with qualitative data. Avoid making assumptions and determinations based solely on numbers — speak to your team to gain their perspective on any numerical findings, and to find out more about what they’re experiencing.

Start at the Beginning: Reduce Time to Open

If you’re looking to boost your team’s Cycle Time, it’s possible that one of the four phases of development will stand out as the one most in need of attention. More likely, however, you’ll identify multiple possible areas for improvement. Resist the urge to focus on all areas at once; you’ll have more success if you debug one aspect of the pipeline at a time. 

In working with thousands of teams, we’ve discovered that refinements made to Time to Open have the greatest impact on overall Cycle Time. PRs that are opened more quickly tend to be smaller, which means they move more easily through the rest of the pipeline: they’re generally picked up for review faster, approved with less back and forth, and result in less risky deployments. 

To reduce Time to Open, you may want to: 

• Coach developers to practice good coding hygiene and keep PRs small, so they flow quickly through the development pipeline.
• Limit Work In Progress, or multitasking, as task-switching can pull developers’ focus and make it difficult to be efficient.
• Identify and reduce Rework, possibly by helping developers get acquainted with unfamiliar portions of the codebase, or ensuring project requirements are clear.

There are other actions that may be helpful, depending on the circumstances. For example, when our engineering team slowed down after making a shift to remote work, it was because a lack of deliberate communication was leaving developers with little perspective on how their work fit into larger team projects and initiatives. Talking to the team helped our VP of Engineering realize that better context and clearer documentation were necessary to help developers make quick decisions and code more efficiently. 

To Maximize Results, Make Improvement a Team Effort 

The most successful attempts at boosting engineering speed will involve the entire team. Conversations with developers can provide critical context for quantitative metrics, making it possible to get a clear picture of the actual patterns behind the numbers. 

In addition, if team members are involved in identifying the cause of a bottleneck and brainstorming possible solutions, they’ll be more likely to commit to implementing those solutions. Once the team reaps the benefits of process improvements, they’ll be motivated to seek further opportunities for optimization, resulting in even more reductions to engineering speed. 

To dig into your team’s data and start identifying opportunities to boost engineering speed, speak to a Code Climate product specialist.