Do you feel like you are accruing all this Technical Debt every week and it slows your whole team down? Do you want to deal with it so badly, but you don’t know where even to start? Did you have “refactoring/rewriting sprints” in the past, and they have failed, and you had to revert? The first advice is to stop calling it “Technical Debt.” And instead, sit down with your team and figure out the list of specific problems that are causing the most trouble in your software right at this moment. Attack the first problem on the list then only. Repeat on a regular basis. In this talk, you will learn WHY you should do that, and HOW to do that. Moreover, you are going to be able to apply it tomorrow at your workplace!

1. Why you should stop
using the generic term
Technical Debt
And start resolving specific problems instead!
by Oleksii Fedorov @ Pivotal
1

2. Why you should stop using the generic term Technical Debt
2
This code sucks!
Let me rewrite it to this
new JS framework!Is it really that
bad?

3. Why you should stop using the generic term Technical Debt
3
“We have so much technical debt!
We don’t even know how to start
fixing it!”

4. Why you should stop using the generic term Technical Debt
4
Why rewrite is 99.99999% a bad idea
• Business valuable features will be put on hold
• If not, then rewrite will have to “race” with the old
system. It is going to end up with more issues.
• Executing a good rewrite requires certain skills.
Are you sure your team has them?

5. Why you should stop using the generic term Technical Debt
5
Skills needed for a good rewrite
• Good, non-over-engineering, software design skill
• Skill for back-filling of tests for existing code
• Test-driven development skills
• Mastery of clean code
• etc.

6. Why you should stop using the generic term Technical Debt
6
Developer with such profile
• software design skill
• patient back-filling tests skill
• TDD skills
• Clean code
• etc.
Will not complain about
technical debt

7. Why you should stop using the generic term Technical Debt
7
They will just refactor code they touch
all the time, bit by bit
WHILE
delivering business-valuable
functionality

8. Why you should stop using the generic term Technical Debt
8
“So when should we do the rewrite?”

9. Why you should stop using the generic term Technical Debt
9
Almost never.

10. Why you should stop using the generic term Technical Debt
10
Make incremental changes towards
the goal all the time.

11. Why you should stop using the generic term Technical Debt
11
“How?!”

12. Why you should stop using the generic term Technical Debt
12
Ugh. I don’t
know.
So what is the issue
you are currently
facing?

13. Why you should stop using the generic term Technical Debt
13
It is just so
outdated

14. Why you should stop using the generic term Technical Debt
14
It is so
convoluted

15. Why you should stop using the generic term Technical Debt
15
Hundreds
of tests break on every
change

16. Why you should stop using the generic term Technical Debt
16
Somebody
else wrote this

17. Why you should stop using the generic term Technical Debt
17
This library is
taking more time than
saving us

18. Why you should stop using the generic term Technical Debt
18
I don’t like this
framework

19. Why you should stop using the generic term Technical Debt
19
<INSERT YOUR
OWN EXCUSE>

20. Why you should stop using the generic term Technical Debt
20
….
Why is that?

21. Why you should stop using the generic term Technical Debt
21
What should have
been a “1-pointer” turned out
to be a “3-pointer”
And how is that a
problem for us?

22. Why you should stop using the generic term Technical Debt
22
Whenever we touch
this module we deliver 10-20
bugs
And how is that a
problem for us?

23. Why you should stop using the generic term Technical Debt
23
Now we are talking!
bonus points if you could distinguish
complaints from real problems.

24. Why you should stop using the generic term Technical Debt
24
What just happened?
1. Talk about a specific problem at hand
(instead of a generic complaint/feeling)
2. Figure out the reason behind the problem
(5 WHYs)
3. Talk about real specific impacts of a problem
(e.g., unexpected complexity slowing team
down, screwing with estimates, harming
mental health of team members, etc.)
4. Start tracking all of the above

25. Why you should stop using the generic term Technical Debt
25
“I know which problems are serious.
Now what?”

26. Why you should stop using the generic term Technical Debt
26
Identify which problems are worth fixing

27. Why you should stop using the generic term Technical Debt
27
Wishlist
So this module, to
which product area it
belongs?
No need to fix it
now then

28. Why you should stop using the generic term Technical Debt
28
Hold on. It also
affects shopping cart
heavily!
Well. This IS a problem!
Let’s decouple them

29. Why you should stop using the generic term Technical Debt
29
“Product areas?”

30. Why you should stop using the generic term Technical Debt
30
Yep.
We need to think about these problems
through the lenses of Product as well.

31. Why you should stop using the generic term Technical Debt
31
Identify product areas that you have
Wishlist
Checkout
Shopping
cart
Offers
search/filter
And more…

32. Why you should stop using the generic term Technical Debt
32
How much more value business will gain
if it could work in Area X twice as fast?
Wishlist
Checkout
Shopping
cart
Offers
search/filter
And more…
1
4
5
5

33. Why you should stop using the generic term Technical Debt
33
On a horizon, how frequent business
wants to change Area X?
Wishlist
Checkout
Shopping
cart
Offers
search/filter
And more…
1
4
5
5
frequent
frequent
rare
maintenance

34. Why you should stop using the generic term Technical Debt
34
What problems do we have in the Area X
and how severe they are?
Offers
search/filter
4
frequent
Shopping
cart
5
frequent Checkout
5
rare
Wishlist
1
maintenance
• bad library Z
• flakey test suite
• etc.
• too coupled
with Wishlist
• low test
coverage
• etc.
• Filtering is
very slow
• Tests are
too coupled
• etc.
• Very long
methods
• etc.

35. Why you should stop using the generic term Technical Debt
35
Now you should prioritise these problems
And start scheduling them in iterations

36. Why you should stop using the generic term Technical Debt
36
And one last anecdote

37. Why you should stop using the generic term Technical Debt
37
BTW, today I’ve been
working on this feature for
checkout product area
Yeah, what’s
up with it?
I’ve split one of
the long methods while working
on it. Everybody on the team is
happy!

38. Why you should stop using the generic term Technical Debt
38
“And, most importantly
I’ve understood how Checkout works
much more than ever before!”

39. Why you should stop using the generic term Technical Debt
39
Let’s recap
1. Track specific problems, their WHYs, and
their impacts on team/business
2. Track importance of product areas
3. Be aware of how issues affect product areas
4. Prioritise most impactful problems (max ROI)
and schedule 1-2 for your next iteration
5. Refactor small issues “inline” while delivering
(Campsite rule: “Leave campsite cleaner
than you’ve found it”)

40. Why you should stop using the generic term Technical Debt
40
Thank you!
Q & A time!
Learn more about technical debt and more at
ThroughLensesOfCTO.com