How do you manage technical debt?

Published Jun 13, 2017Last updated Jun 14, 2017
How do you manage technical debt?

At times, it's necessary to make compromises for the sake of efficiency.

We've probably all been there β€” writing quick solutions in order to save time. But we also know that bad code is a burden. If not managed properly, the technical debt incurred eventually becomes unmanageable. 😱

What do you (and your team) do to identify and manage technical debt? πŸ€”

Let us know in the comments section πŸ‘‡ or in your own post.

Discover and read more posts from Codementor Team
get started
Enjoy this post?

Leave a like and comment for Codementor

Ives Stoddard
2 months ago

To manage technical debt:

  • define it (what constitutes debt; is it maintainable vs. suboptimal vs. flaky/flawed)
  • track it (estimate of time to fix, and/or risk of not fixing it), same system used for project work
  • create a budget for tech debt work (allocated time per sprint or a dedicated sprint)
  • regularly review and prioritize tech debt work (low hanging fruit, effort/impact, or risk/effort)
  • look for opportunities to reduce future tech debt by encouraging better design (TDD, test coverage, code reviews, paired programming, knowledge sharing, professional development, lunch-and-learns)

There are several models for negotiating what to prioritize. Different models apply to different teams. A security team might be concerned with effort & solution cost vs. risk, whereas a product team might be focused on dev time vs. features / growth / cost reduction. Some models work better than others when external input is required (customers or other departments). Some approaches from product management: https://foldingburritos.com/product-prioritization-techniques/

In the simplest form, each person is allocated X number of units of time to spend where they see fit. Using those units as voting points can help drive consensus / focus across the team as to what would add the most value.

Some questions to ask during that process:

  • does something need to be fixed by a certain time? (release date, compliance review, performance / scaling issue)
  • is the problem blocking new work or potential features / improvements? (how hard is it to add features or refactor old code?)
  • what is the impact if we don’t fix this problem? (are we losing money? are we losing time or productivity? will fixing it resolve those problems?)
  • will fixing it potentially be a multiplicative effect? (is this a dependency other components rely on? will it improve daily productivity / efficiency for the whole team, like flaky or failing test suites?)
  • is fixing this problem related to ongoing work? (reducing mental tax of working on multiple unrelated projects)

Start small and simple. Refine as needed.

Peter Arnold
3 months ago

Set aside a debt budget with your product owner so she can assign 10% of your sprint capacity to tech debt jobs. And make sure you do the following two things constantly; unit tests to convince yourself your code is correct and code reviews to convince others.

Alex Piechowski
3 months ago

Three words: Test Driven Development.

Show more replies

Get curated posts in your inbox

Read more posts to become a better developer