Schedule a call

Technical debt arises whenever you decide to do something that requires effort to correct at a later date.

Technical debt example

For example, if you’re writing code in a programming language which hasn’t been updated in years and doesn’t support modern approaches to testing and development (like unit tests), then this is an example of technical debt.

You might decide not to migrate away from this old version of the language because it would be too much work or cause too much disruption – but since this decision has already been made, there will now be extra work required later on to make changes in future versions.

Why technical debt emerges in agile development

Development teams encounter technical debt for several reasons, both internal and external:

  • Fixed deadlines
  • Lack of planning
  • Lack of communication and alignment
  • Lack of skills: developers without domain knowledge, insufficient automation, lack of QA and testing (i.e. test-driven development), etc.
  • Neglecting quality: cutting corners on code reviews, letting bad code into production (e.g., “it works on my machine”), lack of automated tests or other forms of verification/validation (e.g., static analysis).
  • Poorly defined requirements: vague descriptions in user stories with no acceptance criteria, feature branches that are never merged because they’re not ready yet, unclear acceptance criteria for MVPs, incorrect assumptions about the architecture needed to support new features, etc.

In short, technical debt is any component that detracts from the value proposition delivered by an agile software project—and there are plenty out there!

Types of technical debt

We distinguish 4 types of Technical Debt

  • Planned Technical Debt occurs when developers know that there is a right way and a quick way to solve a problem, but they consciously choose the latter due to time constraints.
  • Accidental Technical Debt happens because of a lack of knowledge or low standards. It may also result from poor communication within the team and/or between departments.
  • Unavoidable Technical Debt – during the design process, the team tries to develop a future-proof system. However, as the system evolves and the requirements change, their solution might not be viable anymore.
  • Bit-rot – develops over time, when the quality of software deteriorates due to incremental changes, especially when they are made by different developers.

How to manage technical debt in agile

Everything we do affects technical debt and we should be aware of the impact. Throughout every sprint, we need to know how much refactoring has been done and how much more is necessary. This can be measured by tracking hours spent on refactoring and the size of user stories in the backlog compared to the agile team’s velocity.

Did you know…

Refactoring is the process of improving code without changing its external behaviour.

We need to plan for paying off technical debt in every sprint. It’s impossible to know the exact consequences of each change until it’s implemented, but this doesn’t mean you shouldn’t have some idea of what needs to happen down the road. This ensures that when problems arise, they don’t derail your team’s progress.

Example of technical debt management

If you know that two weeks from now you’ll need all new API endpoints and authentication systems, then now would be the perfect time to start planning out how those changes will occur without impacting other projects or causing unnecessary delays.

Technical debt can be a good thing…

While technical debt is a useful tool, it must be managed carefully. If left to grow unchecked, it can have a negative impact on the team, product and business.

Technical debt can be managed by paying it down with refactoring. By doing this, you’ll improve the codebase while reducing technical debt at the same time!

In conclusion, technical debt can have its merits as it may save a lot of time. It can help land a critical customer when the product is released early or achieve cost savings that can be invested elsewhere. – as long as we keep its existence in the back of our heads and allocate time to deal with it in the (near) future!

Originally published May 11, 2022 11:32:49 AM, updated May 11 2022.

Don't forget to share this post!