Cycle Time Breakdown: Tactics for Reducing Coding Time

The Issue: My Coding Time Feels Too High

Cycle Time is the Dev Manager’s Super Metric. So naturally, the conscientious Dev Manager will want to pay close attention to Coding Time, the very first segment of a project’s journey along the Cycle Time path. Keeping Cycle Time “all green” is the goal, but this is often difficult because there are a lot of moving parts that go into managing Cycle Time. One of those moving parts that are hard to keep in control of is Coding Time.

Coding Time is defined as the time between the first commit made to a branch to when a pull request is submitted. As a general rule, you want your coding time to be two to three days. Anything above four days is considered worrisome, and a Coding Time above seven days is a real problem. Many elite teams are able to measure Coding Time in hours, not days.

In the past, we could measure the notion of Coding Time only anecdotally. Perhaps you could keep track of how the coding on a project was going by the reports in a daily standup.

However, these days, managers are demanding more — they want hard data. LinearB provides an overview of Cycle Time for all your projects on the main dashboard that includes a clear indication of the status of your coding time. This dashboard is data-driven, based on the work committed to your code repository.

Here you can see that coding time is turning orange- meaning that it is getting worrisome and should be looked at more closely. At this point, things are heading in a sub-optimal direction, but the dashboard shows this fact to you in real-time. You are able to quickly see any bottlenecks almost immediately just as they begin to be a problem.

What’s the cause?

There are three main reasons why a branch might have high coding time:

1. The project is too large

2. The project is too difficult

3. The project is languishing

The Project is Too Large

This is probably the most common reason that Coding Time expands beyond desired boundaries. The branch the project is based on will often have many commits. The “chunk” of work is too big to complete in the standard set for normal coding time. In general, the Coding Time is longer because there is simply too much work and not enough time.

The Project is Too Difficult

Sometimes, your project might be broken down into appropriately sized chunks of work, but it turns out that a given chunk of work is harder than anticipated.

Maybe the problem wasn’t completely understood, and the effort required to do the task was greater than originally thought. Or perhaps there were a number of “unknown unknowns” that were discovered, making the project bigger than anticipated. Another indication of this problem is high levels of code rework and refactoring.

The bottom line here is that things were more difficult than anticipated.

The Project is Languishing

This one is pretty simple: The Coding Time is taking longer than expected because the project was started, but left alone unworked. Most likely the developer was required to turn to other tasks based on new priorities, and the branch was left unaltered for a long period of time.

Investigating High Coding Time

The first thing to do about growing Coding Time is to find out which projects or branches are the ones causing the problem. In order to do that, you can drill down into the LinearB dashboard and take a look.

To look more deeply, you can click on the little arrow in the upper right corner of the Cycle Time Box.

Doing that will take you to the Branch View of your repository. From there, you can see all the branches that are affecting your coding time.

For instance, the top branch below had a coding time of almost eight days — a length of time that contributed to the Coding Time for the team being higher.

Note, too, that you can see the exact contribution that any branch is making to the overall Cycle Time by simply hovering your mouse over the Cycle Time column of the given branch. Thus you can quickly see which branches are causing problems for your Coding Time.

For example, by analyzing our own coding time data over the past fifteen months, we’ve found that fewer than 20% of Pull Requests make up the majority of coding time issues. Oftentimes these are Pull Requests that were forgotten about due to a high level of context switching or where the chunk of work was too large.

Once you determine where the long coding times are, you’ll want to know why those branches are causing a problem. That is — which of the three reasons above do the problematic branches represent.

Once a branch has been determined to have a Coding Time problem, you can click on the name of the entry and be taken directly to the git page for that branch, where you can determine what the issue is, whether it be too much work, code churn, or the branch simply isn’t being worked on.

From there, you can work with your team to correct the issues going forward and get your Coding Time back into the green.

Preventing High Coding Time

Naturally, what you really want as a manager is to prevent Coding Time from being a problem in the first place.

If you are not already using LinearB and want to do things like track Cycle Time and Pull Request Size, sign up for a free demo of the product today!

The first thing you can do towards that goal is to educate your team on the need for dividing your work into small, manageable chunks. Pull requests that are too large are a clear indication that the chunks of work are too big. Big Pull Requests will also tend to make PR Review Time longer as well.

Pro Tip: High-performance engineering teams try to break their work into less than 150 code changes per Pull Request.

You could check the Branches page each week, looking for large Pull Requests that indicate long Coding Times.

You might then even bring this metric into your sprint retrospectives. If your team agrees that improving Pull Request size is important, you can set it as a goal for your next sprint and celebrate a win during the retrospective.

Second, in order to warn your team about large chunks of work, you can configure the Work at Risk notifications to notify you of branches that are heading in a bad direction so you can take corrective action before they become real problems.

To allow you to keep a close eye on Coding Time, you can create a custom dashboard with PR Size and Coding Time on it so that you can easily check on these important values at any time.

Finally, you might check the Daily Digest notification message for branches that have more than 100 code changes, stuck work, and pull requests with more than 6 comments. These are the branches that are very likely problematic and worth investigating before they cause Coding Time to rise.

The End Result

Keeping Coding Time, and thus Cycle Time, under control is a critical means to continuously improving your software development process. By monitoring Pull Request size, keeping an eye on individual branches where Coding Time is pressing up against your limits, and by warning you and your team about Work at Risk, you can ensure that your Coding Time stays under control.

But more importantly, LinearB can help you ensure it doesn’t happen in the first place. Our tool lets you recognize that there is a problem, dig in to find where the problem originates, and take the necessary steps to correct things. If you are not already using LinearB and want to do things like track Cycle Time and Pull Request Size, sign up for a free demo of the product today!

Originally published at https://linearb.io on July 16, 2021.