Rework Costs Your Company Millions — How to Cut Back?

On average, a software development team reworks about 26% of its code prior to release. Even after accounting for necessary changes, those wasted hours can cost a medium-sized business upwards of $4.7M a year.

Still, when engineering leaders look to cut costs, they often look at departmental spending. Software licenses, discretionary expenses, and even salaries may come under scrutiny.

But not all costs come with such a clear price tag — inefficiencies in the software development process are harder to quantify, but much more expensive.

According to a 2017 DORA white paper, , the cost of Rework in software development is staggering, setting businesses of all sizes back millions of dollars a year.

Source: , DORA, 2017.

Unnecessary Rework, or code churn, is a significant source of waste across all industries. As the authors note, when organizations reduce their levels of Rework, they’re “essentially getting additional capacity without having to recruit and hire – just by improving processes.” Not only are they recouping the cost of wasted time – if they reinvest that time in the business, they’re realizing gains from those additional working hours.

Though the costs calculated in the DORA report are astonishing, they’re also conservative. They account for the dollar value of wasted time, but the cost of Rework in software development extends beyond the cost of unproductive hours. Unnecessary Rework can also harm morale, which can lower productivity and make it difficult to retain talented developers.

Using DORA’s formula, it’s possible to determine how much money your department is wasting on unnecessary Rework.

If you can find ways to evaluate, diagnose, and reduce your levels of Rework, you can begin to make a dent in one of your largest hidden costs.

Identifying Unnecessary Rework in Software Development

Information about your team’s Rework is already available in your VCS. Using , you can analyze Rework at both the team and individual level and begin to observe trends.

When you’re just beginning to tackle Rework in your organization, start by establishing your team’s baseline. How much Rework is normal for your team? For an individual?

You can use that information to identify teams or individuals with high levels of Rework relative to the rest of the department. It can also help you spot any general organization-wide upticks.

Source: . Green highlights high performance, while red indicates an area in need of improvement, relative to the rest of the team.

These deviations from your baseline represent anomalies worth investigating, though it’s important to note that your investigation won’t always reveal waste. Some Rework is expected, even necessary — and in some cases, avoiding Rework for the sake of bringing your numbers down will only convert that cost into technical debt, which you’ll pay for later.

Through conversations with your team, you’ll be able to put your observations in context and determine which Rework is anticipated and which needs to be addressed.

Rework at the Individual Level

Let’s say you’ve identified a developer whose Rework levels are higher than the rest of the team. Check that observation against what you already know about their circumstances. If the developer is a recent hire still getting familiar with the codebase, or a team member working in a new programming language, it’s reasonable to expect higher-than-usual levels of Rework.

If this number doesn’t decrease over time, you can treat it as a coaching opportunity. Rework is a leading metric, and high Rework levels can signal that additional hold-ups will appear further down in your development pipeline. Use specific units of work as a starting point, and talk to the contributor about their biggest stumbling blocks. Together, you can develop a strategy for improvement, like arranging for a pair programming session with a more senior member of the team.

Rework at the Team Level

You can apply the same strategy to teams. When you notice that Rework is trending upward — on one team or across the organization — use that as a starting point for conversation. It can be helpful to bring specific units of work to your retros or stand-ups, so you can kick off the discussion around something concrete. Through these conversations, you may learn that the team has been struggling with unclear technical documentation, or suffering through .

From there, you can work together to address the issue. A team whose Rework is a result of poor documentation may benefit from taking some time to clarify product specs, while one dealing with a lack of communication may benefit from opening new channels for sharing information.

Set Targets to Decrease Rework

Once you’ve begun to evaluate your team’s Rework, you can use that information to towards those goals. Set a target that is ambitious, but achievable, for your team. If you want to get to 20% and you’re currently at 30% Rework, it might be productive to aim to get to 20% in stages, rather than all at once.

What Will You Do With Your “Free” Time?

Cutting down Rework is more than just a cost-saving measure. It’s a chance to reinvest in your department without spending money. Time that used to go to waste can be used for innovation. Developers who were previously frustrated by their inability to make progress will be motivated by the opportunity to add value, and will be more likely to stick around. With a stable team and more hours in the day, your department will be able to make an even bigger impact.

Previously published at