Software engineers are under constant pressure to deliver more work in less time. Product managers want shorter timelines, and leadership often views AI as the magic pill that will make everything go faster.
But what if I told you that the bottleneck in your software development lifecycle probably isn't the time it takes to write the code? It's actually everything else.
Time in active state vs. inactive state
When looking at team productivity, an important metric to pay attention to is throughput — how much work the team completes in any given time period. For example, you might look at how many tasks the team completes each day.
One key to increasing throughput is often overlooked: reduce the amount of time any given task spends in inactive status.
Any given task can only be in one of two states — active or inactive. When a task is in an active state, you are actively working on it (creating designs, writing code, reviewing code, etc.). When a task is in an inactive state, you are not actively working on it. If you were to examine your team's tasks, you'd likely find that each task spends most of its time in an inactive state.
Inactive states
So what are some examples of when your task is in an inactive state?
- You are waiting on a design decision
- You are waiting on a response from a product manager
- You are waiting on someone to review your code
- You are waiting on someone to test your code
- You are waiting on automated tests to pass
- You are waiting to merge your code
- You are waiting to deploy your code
Let's consider this fictional example: Let's say you've started on an engineering task. You spend 25 minutes writing the code and then create a pull request (PR). You then notify your teammates that you'd like a code review.
The PR sits waiting for a review for 2 hours and then is reviewed by someone. They take about 5 minutes to review the PR. They have some feedback and request some changes. You spend 10 minutes making those changes, push up the commit, and ask for a re-review. 1 hour later, your teammate re-reviews for another 5 minutes and approves the PR.
You add your PR to the merge queue, and it takes CI another 30 minutes for the PR to merge. Then you go to deploy your PR, but deploys are currently locked due to a production incident. 2 hours later, deploys are unlocked and you're able to deploy your PR. The deploy process then takes 15 minutes to complete.
Finally, your code changes are in production.
Now, let's look at where our task spent its time. It was only in an active status for 45 minutes. But it was in an inactive status for 5 hours and 45 minutes!
Reducing time spent in inactive status
A lot of things went wrong in that example scenario, and the actual numbers will vary each time. But consider what things we could do to make our process more efficient:
- Code authors: Make your PR easy to review by keeping it small, doing self-reviews to catch easy mistakes yourself, and having a clear PR description that explains what you're doing and why (and, if applicable, includes screenshots or videos)
- Code reviewers: Review PRs as soon as they are put up for review
- Everyone: Respond to questions quickly
- Code authors: Respond to PR feedback quickly
- Code reviewers: Re-review PRs quickly
- Everyone: Have a fast CI pipeline
- Everyone: Avoid blocking deployments
- Everyone: Unblock deployments quickly when they do get blocked
Some of these things are well within your control. Others are not. The key is to identify where the bottlenecks happen in your process and then find ways to reduce time spent in those bottlenecks.
Some bottlenecks are technical. Many bottlenecks, however, are people and process problems — they require everyone to collaborate effectively and to uphold various working agreements.
Just remember, writing the code was almost never the bottleneck.
Top comments (0)