Whether we know it or not, every time we deliver a feature we also deliver technical debt. This debt remains largely invisible, it isn't tracked, it isn't visible on our information radiators and we very seldom tell our clients about it. The closest we come to acknowledging technical debt is bugs, mainly because our users tell us there is a problem, so we can't ignore it. Technical debt shouldn't be invisible, it's as real as the features we deliver and we should start treating it so. In this talk I propose a technical debt model which can be used when identifying technical debt, furthermore I propose a low friction technique for integrating technical debt into your current SDLC process.

1. Delivering
Technical Debt
Brendon Page
@brendonpaginate

2. Software Developer
@brendonpaginate
#DeliverTechnicalDebt

3. Overvie
w
Origin
Evolution
Delivering

4. The Audience Survey
Who wants
to explain it to
a team
member?Who has
heard of
Technical
Debt?

5. Conversations
Between Us
Common
understanding
Meaningful
conversations
Big Problem

6. Origin

7. The Experience
Report
Ward
Cunningham
“the debt
metaphor”
WyCash
financial
system
1992

8. The Experience
Report
"Shipping first time code is like going into
debt.A little debt speeds development so long as it
is paid back promptly with a rewrite...
Entire engineering organizations can be
brought to a stand-still under the debt load
of an unconsolidated implementation, object-
oriented or otherwise."
The danger occurs when the debt is not
repaid. Every minute spent on not-quite-right
code counts as interest on that debt.
1992

9. The Experience
Report
"Shipping first time code is like going into
debt.A little debt speeds development so long as it
is paid back promptly with a rewrite...
Entire engineering organizations can be
brought to a stand-still under the debt load
of an unconsolidated implementation, object-
oriented or otherwise."
The danger occurs when the debt is not
repaid. Every minute spent on not-quite-right
code counts as interest on that debt.
1992

10. Good
Metaphor
It stuck
Explain
the
rewrite
Universal
terms
Yes

11. Evolutio
n

12. Interpretations
Difference
between
Poor
code
Good job
later
“Hacking it”
“Doing it
Properly”
Okay to

13. Metaphor
Explained
Code should
always reflect
understanding
Not to
explain
writing
bad code
Explain
refactoring
to
Business
2009
Robert
C.
Martin
“A Mess is
not
Technical
Debt”
Even
if
partial
Confusion
2009

14. Technical Debt
Quadrant
Instead of
debt / non-debt
debates
Metaphor
2009
Communication
tool
Martin
Fowler
Convey
thinking
about design
decisions
Classify
debt
Responsibility
and
Awareness

15. Technical Debt
Quadrant
Deliberate
Inadvertent
“We don’t have
time for
design”
“We must ship
now and deal
with the
consequences”
“What’s
layering?”
“Now we know
how we should
have done it”
Reckless Prudent
Awareness
Responsibility
“This code
barely
changes”
2009
Where
you
are
Stimulate
meaningful
conversations
I like this!

16. Deliverin
g

17. What?
Build
common
understanding
Map
metaphor

18. Development Process
Feature / Story
Developer
Learning LearningLearning
Code
Domain
Principles
(SOLID, DRY
… etc)
Domain
Tech
Domain

19. Mapping the Metaphor
Feature / Story
Asset
Principal
Principal is
what you pay
interest on
How?
Developer
Learning LearningLearning
Code

20. Interest
Feature / Story
Developer
Learning LearningLearning
Code
Idea
Idea
Costs
cognitive
resources,
interest!
Code
state
Mind
state
… oh
yea it’s called
“Person” now
Translation
Temporal
Mapping
User
==
Person
Where is my
“User” class

21. Paying Debt
Feature / Story
Code
Developer
Learning LearningLearning
Learning LearningLearning Because
“Person”
is called
“Person”
Less
cognitive
resources
Consolidate
learning
(refactoring)
No
temporal
mapping
needed

22. Unconsolidated Code in a Team
Feature / Story
Developer 1
Learning
Developer 2
Code
???
???
Developer 2
pays 100%
interest

23. Consolidated Code in a Team
Feature / Story
Developer 1
Learning
Developer 2
Code
Learning
???
Developer 2
pays 0%
interest

24. Deliver your learning
Feature / Story
Code Deliver
Kept
internal
Code
Developer
Learning LearningLearning
Learning

25. Deliver your learning
Feature / Story
Code
Deliver
Code
Developer
Learning LearningLearning
Learning

26. How?
Record it
Treat it like
a feature
Prioritise,
track, …
Hard

27. Red Bin
Ability to
distinguish
them from
features
LEAN
manufacturing
Place anyone
can put
Red Bin Items

28. The Red Bin
Feature
2
Red
Bin 3
Red Bin Backlog Queue WIP Done
During the course of the day During the stand up the next day

29. Deliver learning like a feature
Red Bin Backlog Queue WIP Done
Feature
2
End of the sprint

30. Why?
Honest
delivery
Project
health
indicator
Better client
relationships
Embrace
& address
your debt

31. Summar
y
Metaphor
Colourful
past
Honest
delivery
Define
what it means

32. Thank you!
Questions?
@brendonpaginate
#DeliverTechnicalDebt