| « Five Tools I Can’t Develop Without | Let’s Talk About Facades » |
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.
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.
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.
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.
Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP
Posted on 3/11/2014 at 7:00 am
Greg wrote at 3/11/2014 10:22 pm:
Making the case should be easy – Ward Cunningham came up with the debt metaphor precisely to explain to management why code needed to be revisited, refactored and maintained.
This is an incredibly useful sub 5 minute video from the many himself – I firmly believe that every manager should watch it :)
Juan Antonio Galan (@ja_galan) wrote at 3/12/2014 4:25 am:
Great post as usual Brandon!
The only problem I see is that you’re assuming that after your big refactoring push everything is going to work perfectly, but is that really the case? Are you 100% sure you know what the problems are and how to fix them? The bigger the refactoring is the more chances that you don’t do it right.
Not saying it’s not worth it but generally I’m more in favour of a continuous refactoring effort, refactoring small parts that you understand well.
| « Five Tools I Can’t Develop Without | Let’s Talk About Facades » |