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

Let's talk