Paying technical debt

Paying technical debt

Oversimplified version

The purpose of this is to get an idea of how we could pay the technical debt so we would maintain a high-quality codebase.

Goals:

  1. Agree on simple ways of dealing with it
  2. Prepare a plan of cleaning high technical debts
  3. Improve the current code base quality

Background

“A common debate in software development projects is between spending time on improving the quality of the software versus concentrating on releasing more valuable features. Usually, the pressure to deliver functionality dominates the discussion, leading many developers to complain that they don't have time to work on architecture and code quality.”

Tech debts can be divided into:

  1. External (UI and defects)
  2. Internal (architecture)

Screenshot 2021-10-15 at 12.03.57.png

Problem Statement

Working with low-quality code base results in:

  1. More time needed to understand the current workflow
  2. Some new features cannot be done without refactoring
  3. Some features might be blocked because of it
  4. Those debts get stale and pile up resulting in hard to fix them

Possible Solutions:

  1. We remove small and medium debts with new features thus resulting in bigger estimates but rapid quality grow
  2. We dedicate some time in a sprint/month/quarter to clean up bigger technical debts

Is quality worth cost | Source