In many development shops where I’ve worked, there’s a consistent struggle between developers who want to “do it right” and management that wants to “just get it shipped.”
The problem stems from the pride developers feel in their work coming up against the business realities faced by managers and company leaders, who are focused on making sure everyone gets a paycheck each Friday.
But what developers don’t often realize is that technical debt has a true business cost – one that can be quantified in hard numbers. And by quantifying this business cost, developers can often have an opportunity to fix the problems that have been frustrating them for a long time.
A look at the math
Company leaders want products to be shipped so that they can sell those products. It’s how everyone ends up with a paycheck. No product, no customers, period. And so, anything that seems to stand in the way of shipping products is seen as unnecessary.
Yet in many companies, technical debt stands in the way of profits, as well as shipping.
Consider: a five person development team that is slowed down by four hours per developer per week by technical debt essentially wastes 20 productive hours per week. At $50 per hour per developer, that total cost per week in wasted time is $1,000, or $52,000 per year.
The problem only gets worse as salaries rise, teams grow, or product complexities increase. And all of these things will happen, slowly, over time.
I know few CEOs that would look at saving $52,000 a year as a waste of time and effort, especially if the work can be done for less. For example, if the team can refactor or write tests for a good bit of the code in a two-week span, the company stands to save $32,000 in its first year.
Making the case to your management
When it comes to making the case, you had better be prepared with numbers.
You need to illustrate precisely how much time is being spent fixing problems that could be fixed in a big refactoring push. You need to be able to highlight the savings to the company, at least in terms of man hours, that will be achieved. And you should know exactly what problems you want to fix. You’re going to have to prove it.
Knowing the dollar amounts isn’t important; that’s for the management team to figure out. But hours convert to dollars.
Management still may reject your plan. If that’s the case, it may be time to look for alternate employment or engage in a “subversive refactoring program” where you refactor as part of estimates for other features and components. Still, most managers, when presented with potential cost savings, would jump on the opportunity, and if you make your case effectively, you’ll be successful.
The bottom line
Technical debt has a very real, and often very high cost to software teams and companies. Identifying and eliminating this cost as much as is reasonable will work wonders on your team, and your company.