I'll go first.
In my experience, it seems that just about every engineer I've worked with is on board with reducing tech debt, but the struggle mainly comes from convincing upper management that these things are worth working on.
I'm fairly convinced it's due to some combination of the following:
- inability to persuade on my part
- inability of middle management to fight for prioritizing reducing tech debt
- inability of upper management to understand the consequences of ignoring tech debt until it's too late
I'm curious to hear others' experiences fighting this fight.
Top comments (5)
A lot depends on who exactly needs to be convinced and what is most important to them. An engineering manager is going to see it differently than a business executive.
@Chapman 's point about it being like financial debt is a good one, because it's the same core concept: you're borrowing against your future to achieve a goal in the short term. Often it is accepting that code will be harder to work in down the road in favor of hitting a deadline. Just like financial debt, you'll be buried in interest if you don't eventually start paying it off.
That's more of a high level concept, but you also want to start thinking about it in tangible terms. Can you point to specific examples of a bug that was introduced or a deadline was missed due to working in code that needs a refactor? Even better, can you assign a value to it? Perhaps down time in the app from a bug, developer hours (which ultimately == $$)?
At the same time, you can be as convincing as possible, but some people or work cultures just aren't willing to listen (which means you have another problem). Your happiness and stress are also two factors in this, and if a company wants to retain you for the long term, it is in their best interest to make sure that tech debt of all things isn't causing them to lose employees.
That's excellent, gathering some data to show the financial cost to the business due to existing technical debt. I think that goes a long way, especially for upper management.
Yup. You can roughly log how long it took you to fix a bug or how many bugs were created as a result of a change and multiply that by an average hourly or daily rate a company is paying for a developer. Especially if it impacts multiple developers!
I have found that prioritizing technical debt is much like paying down financial debt. The idea is to prioritize from smallest to largest, and snowball your gains into tackling larger debt. Once you solve the smaller issues one at a time, you will gain steam and acceptance from management to tackle bigger issues. They will gain confidence in your plans as you prove successful in smaller issues. Just make sure your smaller successes actually fit into your plans for larger issues.
That's great advice! Start small, see some good successes and have data you can point to, and keep moving onward and upward.