Investing in Technical Debt

Posted by Darin Pantley on August 28, 2017

The Situation

Technical debt backlogs are like mutant weeds that excel at growing under any conditions.

I’ve been a member of multiple teams that have tracked technical debt items in their own backlog. We would have a backlog for items related to the code we were releasing and a separate backlog dedicated purely to technical debt.

I’ve never seen a technical debt backlog shrink itself. Someone always has to intervene, figure out where the debt is coming from, and come up with a plan to address it.

Types of Technical Debt

I agree with Agile Mike, who wrote in his aptly titled article Technical Debt that technical debt can be divided into three main types: naïve, strategic, and unavoidable.

Here’s a quick summary in my own words:

  • Naïve: choosing a bad option
  • Strategic: making a wise trade-off
  • Unavoidable: proceeding with the only option

I would also add that sometimes you can avoid technical debt entirely by finding an excellent solution.

Managing a technical debt backlog can be overwhelming, but take comfort in the fact that there are only so many things you can do about it. For starters, consider the following options.


Invest in the appearance of the list

  • Stop adding new items to the list

    • I’ve found people don’t take this option very seriously, but it has some value.
    • It buys you time to triage the list and regain some sanity.
    • If your list is out of control, making it longer isn’t going to help.
  • Move the existing items to another list

    • If you have ongoing work that relates to an item on your list, you can track everything in the same location: somewhere that isn’t your technical debt backlog.
    • If several items are related, but you have nowhere to put them, call it a feature, create an epic, form a release, or whatever your process is and give them a new home. Then schedule it in with your usual work.
  • Delete tasks from the list

    • This may be appropriate for obsolete requests and nice-to-haves that you’ll never get around to doing.
    • A task hasn’t been updated in eons? No recent comments? Delete!
    • It might help team morale to see the list shrink.
    • Vote on which items to keep or discard so everyone can be involved.
    • Don’t worry about losing important tasks. If it’s really that important, someone will add it back to the list.

Invest in the existing code

  • Modularize and refactor code

    • You’ll probably need some unit tests to pull this off successfully.
    • Engineers love writing new clean code.
    • Code is easier to write than to read.
    • You’ll thank yourself later once the spaghetti is removed from your code.
  • Write automation

    • Make your existing tests run automatically as part of every change request.
    • Download a static analysis tool and let it run on a cron schedule.
  • Write documentation

    • Every time someone asks a question, add it to the docs. Then tell them the answer is in the docs and give them a link.
    • Use automatic documentation generation tools so the docs stay up to date with your code.
  • Teach team members or other teams

    • The more people that are familiar with a code base, the more people you have at your disposal to help you improve it.
  • Standardize code style for readability purposes

    • Use a tool to do this automatically, if at all possible, and you’ll save everyone a ton of wasted hours in code reviews.

Invest in time management

  • Dedicate more time to fixing technical debt

    • You’ll initially release less code, but eventually you’ll have fewer things preventing you from releasing code.
  • Dedicate less time to fixing technical debt

    • If you’re under a time crunch because angry customers are beating down your door or you have a release going out the door, it may be appropriate to pause work on technical debt until you can get a handle on things, but don’t forget to come back to it next week!
    • Initially you’ll release more code, but eventually you’ll have a maintenance nightmare that slows the entire development cycle to a crawl.
  • Allocate time differently

    • Some people find that having fewer context switches allows for more efficient work.
    • There are many articles about the damage a short interruption can do to the workflow of a software engineer.
    • Dedicate a day to technical debt or encourage team members to work on it during a certain part of the day.
    • You can also assign a person or team to work solely on technical debt. I’ve seen this work.

Invest in process

  • Improve the architecture

    • Invest in new tooling
    • Invest in new infrastructure
  • Strengthen the development process so that tech debt isn’t created in the first place.

    • Improve your Definition of Done
    • Fix tech debt as it arises, when it arises, rather than queuing it for later.
    • Adopting a continuous integration system can help stem the influx of new problems.

Invest in knowledge

  • Get a fresh perspective

    • Talk to someone from another team or from another company.
    • Bring in a contractor.
    • Read books, articles, and blog posts.
    • Attend presentations and conferences.
    • Generate your own original content and share it with others to start a discussion.
  • Help everyone be mindful of priorities

    • Talk about technical debt as a team.

Invest in people

  • Provide an incentive to fix technical debt

    • Free food, swag, a leaderboard, points, recognition, etc.
    • Convince upper management to talk about technical debt as a priority. It’s very empowering to be able to say, “we should do this because our boss said it’s important”.
  • Hire new people

    • Bringing in fresh talent exposes your old problems to new solutions.
    • New hires are less likely to blindly obey old cultural norms that prevent changes from being made.
    • New hires also tend to ask great questions, like “why do we do it this way?”