Technical Debt, Maintenance and Buy-In

Recently I did a blog about managing technical debt mountain and how to go about addressing it. You can read Chipping Away at Technical Debt Here.

That lead into a small discussion on Twitter about getting buy-in from product or higher-ups when feature development continually takes precedence.

I had to do some thinking, and reflection if I'm being honest. I've certainly run into this in the past, but remembering the details of a so-common occurrence was difficult. Once memories started flowing back, I had to then think about, was that the right approach? If faced with this situation now, what would I do?

Before you go out swinging to your leaders, take a moment and think about what needs to be done. Here's a summarized checklist from the original post, but please go read it when you're ready to start tackling this debt!

1. Define Scope
2. Plan of Attack
3. Attack!
4. Maintenance

Once you have scope defined, you can start on your plan of attack, by playing off the below scenarios that fit your situation.

As an example, we'll use a basic hotel booking app. The code in finding a competitive rate for a hotel has proven to be buggy in the past, and it's so old that it's using outdated frameworks. But the effort to update it has been too large to prioritize, so in the debt pile it sits.

When management doesn't care

This is probably worst case scenario, because it signifies there's more serious problems on the team. Another topic for another day perhaps. When you're faced with leaders that don't care about technical debt or project maintenance - you need to sell it, pitch it. This is where talking with money and hours comes in.

• Identify the risks/facts.

  • With lack of tests, and a code structure that's untestable, we will not be able to easily catch bugs before entering production.
  • Outdated frameworks pose a security risk, with known vulnerabilities.
  • Maintainability is decreasing with each patch.
  • Scope is increasing with each patch.
  • We risk losing customers over a poor experience, what if it double books, or doesn't book, or leaves a customer stranded with problems.
  • With previous bug fixes, we've spent about 30 hours maintaining this code in the last month alone. That effort grows with each patch as scope increases.

• Identify the solution.

  • A complete refactor of this code would take about x amount of time with n developers dedicated full time.
  • Refactoring this code will allow frameworks to be updated, removing security vulnerabilities.
  • It would also allow the architecture to be fixed and we can add automated testing, ensuring that our core functionality will not break with each release.
  • With tests, we'd catch problems before shipping software.
  • This code becomes incredibly more maintainable and saves hundreds of developer hours in the future because the risks have been mitigated.

That's a pretty convincing argument.

The entire point is to provide quantitive metrics and the outcome in quantitive metrics where possible. You have to hit the company in the wallet. Paying for extra development hours or losing customers are both things that will hurt business.

It's also up to every maintainer on your project to push in the right direction. If your lead dev/team lead/trusted senior dev(s) is dragging their feet, you're not going to get the buy in that you're looking for. Again, larger problems. But even in the worst environments - if everyone is sticking to their guns, someone has to give in sometime. :)

When there's no time / not a priority

This started out as two separate scenarios, but they're so close, we're gonna group them together. If you're behind on features, it can be hard to find the time to fit in these maintenance tasks. Likewise, if everything else seems to be a priority, it's difficult to get these menial tasks to the forefront.

Bring addressing technical debt up early and often. If you see a break coming up between features, bring it up. Work with your leaders to come up with a plan to tackle it. 10-25% of the sprint to focus on technical debt might be a solution. One rotating "maintainer" that only focuses on technical debt is another. Or one sprint a quarter or two, that will focus solely on technical debt. The good news is, your leaders care, but the follow up is find a compromise that can prioritize features/enhancements while not leaving the rest of your project behind.

Wrap up

It's difficult to navigate these scenarios when technical debt mountain is running the show - SO if you're in a position, try to work in a plan with your leaders before you reach the point of no return. Otherwise, apply pressure often and frequently, like a wound. If all else fails, time to find some leaders that will care what their developers have to say. Whew, spicy. 🥵