Do you know the importance of paying back Technical Debt?

What is Technical Debt?

Technical Debt (or tech debt) is when you defer work that needs doing in your code. And, just like when you defer a payment and accrue financial debt, Technical Debt must be repaid, and it accumulates interest (in the form of reduced velocity) while it remains unpaid.

Technical Debt can occur for all kinds of reasons, for example:

• When you take a shortcut or implement a hack to get a feature out quickly. Sometimes this is because, as a team (including the Product Owner), you've made a conscious decision to take this shortcut because, for example, you need a cut-down version of the feature urgently, or in other cases because of an open bug in a library you depend on.
• Code that is hard to understand after reading it multiple times or a single method that spans multiple screens is also considered to be Technical Debt.

Systems need to have features added to them to continually remain useful (or competitive). As new features are added to the system, often more Technical Debt will be introduced. But as any system ages, it will accumulate Technical Debt.

Example: A developer takes a shortcut to get some early feedback on a new feature

• $100 - Full feature
• $20 - Feature with shortcuts (no tests, dirty code, whatever it takes)
• $80 - IOU via PBI in the backlog e.g. {{ FeatureName }} – Technical Debt - Planned

✅ Figure: Good example - Technical Debt is very visible to the Product Owner

What are the consequences of Technical Debt?

• Fewer product features over time
• More developer friction
• More developer frustration

Figure: Professional Developers survey

The 3 types of Technical Debt

1. Planned Technical Debt

Sometimes you want to quickly implement a new feature to get it out and receive some feedback.

Note: Martin Fowler calls this "Deliberate Technical Debt".

2. Discovered Technical Debt

During a code review, you or the team notice something as part of the system that is clearly Technical Debt. This code is hindering the ability to add new features or is hard to read/understand.

Note: Martin Fowler calls this "Inadvertent Technical Debt".

3. Unavoidable Technical Debt

Every system will accumulate Technical Debt over time. For example, if you built an API with ASP.NET Core 2.0 (which is now out of support), you have Technical Debt because that version is no longer supported. This kind of Technical Debt cannot only negatively impact the productivity of the team, but it can also introduce a security risk. Another example is that the architecture you selected may have been right based on the original spec, but as requirements change or new requriements emerge, this may no longer be the case. The team can choose to refactor now, or accept the Technical Debt and continue to deliver features on the current architecture.

Note: Martin Fowler would also classify this as "Inadvertent Technical Debt".

Get a Verifiably Stable Application

How to repay Technical Debt

Just like a business that receives pre-payment from customers, a software team should be reviewing the size of their liabilities (being the list of PBIs with Technical Debt).

At the Sprint Planning:

1. Show the Product Owner the list of outstanding Technical Debt PBIs
2. The Product Owner should make sure that the developers review the list of Technical Debt list and pick at least 1 PBI to pay back during the upcoming Sprint

Screenshots

Figure: Screenshot of code with Technical Debt comment and link to GitHub Issue

Figure: Screenshot of Technical Debt on backlog

Figure: SugarLearning architecture diagram