Tech Debt

myth or reality

Agenda

Intro - general slides
What is tech debt - opinions
Reasons of tech debt
What it leads to? Consequences
Tech debt estimation
How to deal with tech debt
Features vs Tech Debt

What is Tech Debt?

"Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice"

Martin Fowler

How it happens?

Initial Architecture
Adding new features
New code and structure complexity
Instead of architecture changes -> adding new features
Code became messy (but still adding new features)
Cannot proceed until perform big architecture change

Consequences

High code complexity
Hard to add new features
Hard to test and debug
Performance issues
Long Onboarding

Vicious Circle

Deliberate Tech Debt

There is the right (long) way to implement
And wrong, but fast
When choose fast intentionally -> create deliberate tech debt
Solution -> track this tech debt to fix it before consequences

Accidential Tech Debt

Unkown factors arise and the current design is not good anymore
Solution -> gradually refactor the system
Treat refactor Work Items in the same way as Features

Big Rot Tech Debt

Legacy Code / Old code
Copy Paste everywhere
Initially bad design
Any little new feature -> tons of changes
Solution -> avoid it

Gradual Improvement

Experience from real life

Consider this:

When seeing valuable improvement - do it
If the estimation is big -> creation of a ticket
Taking 2-3 tech debt tickets in every sprint (5-10%)
Constantly improving the code
Removing old unused code
Writing different tests