Technical Debt:
Maintaining Systems in the
Long Run
Eberhard Wolff
Head of Architecture
https://swaglab.rocks/
https://ewolff.com/
Slide 2
Slide 2 text
Why This Talk?
•Handling technical debt is important to succeed in
software development.
•Many misunderstandings
•Goal: Show decisions that can be made about
technical debt.
Slide 3
Slide 3 text
External Quality
•What users see
•Performance, availability
•Important for architecture!
•Quality scenarios
External
quality
Slide 4
Slide 4 text
Internal Quality
•What developers see
•Code quality
•Code structure
•Tests
•Might be related to external quality
Internal
quality
External
quality
Slide 5
Slide 5 text
What is Technical Debt?
•Not just developers need to reason about internal
quality.
•Technical debt:
metaphor to explain internal quality
…and possible decisions about it.
Slide 6
Slide 6 text
Technical Debt
Cost of additional rework
caused by choosing
an easy (limited) solution
now
instead of using a better approach
that would take longer.
https://en.wikipedia.org/wiki/Technical_debt
Conscious
decision
Debt can be
avoided
Slide 7
Slide 7 text
Technical Debt
As with monetary debt,
if technical debt is not repaid,
it can accumulate "interest",
making it harder to implement changes.
https://en.wikipedia.org/wiki/Technical_debt
It can be fully
repaid.
Slide 8
Slide 8 text
Technical Debt
Technical Debt Productivity
Slide 9
Slide 9 text
The Problem with Metaphors
•Metaphors explain something in different terms.
•“Technical debt is like monetary debt for code.”
•But the original point sometimes gets lost in
translation.
Slide 10
Slide 10 text
Origins of the Metaphor
Slide 11
Slide 11 text
Origins of the Metaphor
•Ward Cunningham
•Inventor of the Wiki
•Worked on Wy Cash
•Technical debt: metaphor for finance experts.
Slide 12
Slide 12 text
What Ward Cunningham Meant
•Team learns new facts
about the domain.
•Facts should be
represented properly.
•So: refactor
•If you don’t refactor, you’ll be in debt .
https://wiki.c2.com/?WardExplainsDebtMetapWhat
https://www.youtube.com/watch?v=pqeJFYwnkjE
Slide 13
Slide 13 text
What Ward Cunningham Meant
•Technical debt = lack of understanding.
•No conscious decision
•Can’t be avoided
•Technical debt is meant to be repaid immediately.
•Can debt be fully repaid?
Slide 14
Slide 14 text
Fowler’s
Technical Debt Quadrants
Slide 15
Slide 15 text
Technical Debt Quadrants
Reckless Prudent
Deliberate
“We don’t have time
for design.”
“We must ship now
and deal with the
consequences (later)”
Inadvertent “What’s layering?”
“Now we know how
we should have done
it!”
Slide 16
Slide 16 text
Quadrants & Decisions
•Inadvertent:
Technical debt without a conscious decision.
•Repaying is not so important for Fowler.
•Reckless: Probably the #1 reason for debt.
Slide 17
Slide 17 text
Quadrants & Avoiding Debt
•Deliberate decisions
“Ship now – deal with consequences later”
•Might make sense
•No design
•Stupid (and probably obviously stupid)
Slide 18
Slide 18 text
Avoiding Debt
•Sometimes, debt is OK.
•Avoid recklessness!
•Do sophisticated technical approaches help?
•Not sure
•Technical debt: a cultural problem?
Slide 19
Slide 19 text
The Problem with
Technical Debt
Slide 20
Slide 20 text
Technical Debt Just Happens
•Often no conscious decision
•Technology update
•Now: simpler way to do something.
•Developer leaves company.
•Nobody understand the code.
Slide 21
Slide 21 text
Technical Debt Just Happens
If technical debt is not caused by conscious decision
… how can it help to make conscious decisions?
Slide 22
Slide 22 text
What does 78d mean?
How is it relevant?
Is there a debt-free system?
Should debt be reduced?
Slide 23
Slide 23 text
No Debt-free Systems
•There are different opinions about “ideal” i.e. debt-
free.
•My experience: In every system, there are numerous
potential improvements.
Slide 24
Slide 24 text
No Debt-free Systems
•I have yet to see a system that couldn’t be optimized.
•The question is usually what to fix first.
•A complete inventory of technical debt doesn’t help.
Slide 25
Slide 25 text
Technical Debt is Meaningless
•Technical debt = changing code is hard.
•Irrelevant for code that is not changed
Slide 26
Slide 26 text
Technical Debt is Meaningless
•Diagrams and code might be ugly.
•Architecture should be led by business decision…
not aesthetics.
Technical Debt & Standstill
•Some debt is fine
•Too much technical debt: Standstill
•What now?
•Rewrite?
•Massive, hard to solve problem
Slide 29
Slide 29 text
Technical Debt & Standstill
•Too much technical debt: bankruptcy
•How much is too much?
•Debt invisible
•A dangerous game
•Does the metaphor communicate a possible sudden
bankruptcy?
Slide 30
Slide 30 text
Conclusion: Problems
•Just happens
•No debt-free systems
•Meaningless - unless code is changed.
•Does not facilitate decisions.
•Risk of a standstill
Slide 31
Slide 31 text
All Systems have
Technical Debt
Slide 32
Slide 32 text
Technical Debt Does Not
Facilitate Decisions!
Slide 33
Slide 33 text
Quite a Few Systems Have
HUGE Technical Debt 😱
Slide 34
Slide 34 text
Different Way to Reason
about Quality?
Slide 35
Slide 35 text
Quality Investments
Slide 36
Slide 36 text
Quality Investments
•Investment should have a pay-off
•I.e. repay technical debt where is matters.
Slide 37
Slide 37 text
Quality Investments
•Financial metaphor
•Managers should be used to think and decide about
investments.
•More than a metaphor:
Investing development effort = money
Quality Investments: Pay Off
•Should have a pay-off
•i.e. higher productivity
•No investments in code that does not matter!
•No investments that are too large to pay off!
Slide 40
Slide 40 text
Quality Investments: Pay Off
•No precise estimates
•But rather rough ballpark numbers
•Helps to justify changes
•Helps to evaluate ideas
Slide 41
Slide 41 text
Applications
Slide 42
Slide 42 text
Investments & Domains
Business Differentiation
Model
Complexity
Core
Domain
Supporting
Subdomain
Generic
Subdomain
Buy?
Cost
Speed
Slide 43
Slide 43 text
Investment: Core Domain
•How many more stories can we implement?
•What would the business value be?
•Business value might be used to justify stories.
•How much do we save on maintenance?
Slide 44
Slide 44 text
Investment: Core Domain
•Stories were worth €10 Mio in business value.
•Assume we gain 5% productivity.
•We could spend €0.5 Mio on those improvements
•Management compatible reasoning
•Successful in the real world
Slide 45
Slide 45 text
Investment: Supporting Subdomain
•How much do we save on maintenance?
•Do we gain business value?
•E.g. by better support for core domains?
•Investment might not be justifiable.
Slide 46
Slide 46 text
Some Types of Investments
Slide 47
Slide 47 text
Refactoring
Slide 48
Slide 48 text
Refactoring
•Restructure code without changing its functionality.
•Extract method
•Rename method / class
•…
Slide 49
Slide 49 text
Refactoring
•Not one large change
•But ongoing activity
Refactor-Test
Implement-Test
Refactor-Test
•Done and decided by developers
Slide 50
Slide 50 text
Refactoring
Investment Productivity
Slide 51
Slide 51 text
Refactoring
•Can be introduced by code retreats, pair
programming, mob programming …
•Done and decided by developers
•Really?
Slide 52
Slide 52 text
Refactoring
•Refactoring, tests etc. are a best practice.
•I don’t want to explain it to non-tech people.
•I don’t want to justify it to non-tech people.
•Business people should not have to justify business
decisions to me.
•Why had Ward Cunningham to explain it?
Slide 53
Slide 53 text
Refactoring
•Probably not done if stress level is high.
•So others can still influence it.
•Can lead to bigger changes
•Refactor towards a bigger goal…
each time a part of the system is changed.
•Larger changes: different approach?
Slide 54
Slide 54 text
Rewrite / Rearchitect
Slide 55
Slide 55 text
Rewrite / Rearchitect
•Change to a new architecture
•I.e. Domain-driven Design
•Often starting point for a consulting gig.
•Benefits are obviously.
Slide 56
Slide 56 text
Rewrite / Rearchitect
•Goal is clear: New, great architecture!
•But how to get there?
•Sometimes completely unclear
Slide 57
Slide 57 text
Rewrite / Rearchitect
•Estimate effort to redo architecture
•Estimate productivity increase
•Estimates are common in software engineering.
Slide 58
Slide 58 text
Rewrite / Rearchitect
Investment Productivity
Slide 59
Slide 59 text
Rewrite / Rearchitect
•Huge investment
•Can take several years
•Team will keep current productivity for quite some
time.
•Project might not implement any features.
•Risk
Slide 60
Slide 60 text
Rewrite / Rearchitect
•Investment only make sense if code is changed.
•Is all of the system relevant enough?
Slide 61
Slide 61 text
We want to change the
architecture entirely!
Let’s estimate the time
Can you really invest 7 year
for a big bang rewrite?
Estimation based on gut
feeling
About 7 years
Slide 62
Slide 62 text
Rewrite / Rearchitect
•Smart decision?
•Needs management buy-in
•Estimate total effort roughly
•Probably stay away from it
•Architecture improvement has to take current status
into account!
Slide 63
Slide 63 text
Incremental Investments
Slide 64
Slide 64 text
Incremental Investments
•Do several bigger investments
•Steps towards a new architecture?
•But: Each must pay-off
•E.g. modernize a part
that is changed frequently
that is changed anyways
Slide 65
Slide 65 text
Incremental Investments
Investment Productivity
Slide 66
Slide 66 text
Incremental Investments
•Still big investment
•But: pay-off rather short term
•Improvements can be stopped
•Risk smaller
Slide 67
Slide 67 text
Incremental Investments
•Hard to come up with individual steps that each pay
off.
•No hard science, just estimates and guidelines.
•Is not improving the situation even an option?
Slide 68
Slide 68 text
Remember: Standstill!
Technical Debt Productivity
Slide 69
Slide 69 text
Who Decides about
Investments?
Slide 70
Slide 70 text
Good Craftsmanship
•Unit tests
•Refactoring
•Developers decide about it.
•Do managers even notice these details?
Slide 71
Slide 71 text
Team Budget
•Set aside time to work on quality
•Management might not care about sustainable pace.
•Then the budget assures that something happens.
•But: might not support business goals
•i.e. investment in the wrong places.
Slide 72
Slide 72 text
Management Decision
•Can prioritize business goals
•Ship now vs. invest in sustainable pace
•But: Might have a bias to SHIP NOW!
•Might be the only way to do larger investments.
Slide 73
Slide 73 text
Conclusion
Slide 74
Slide 74 text
Conclusion Technical Debt
•Metaphor for internal quality
•Debt can lead to a standstill.
•Avoid recklessness
Links EN
•Article about Quality Investments (with Felix Müller)
https://www.infoq.com/articles/no-more-technical-debt
•Podcast Technical Debt with Sven Johann https://www.se-
radio.net/2015/04/episode-224-sven-johann-and-
eberhard-wolff-on-technical-debt/
•Managing Technical Debt with Sven Johann
https://www.infoq.com/articles/managing-technical-
debt/
Slide 77
Slide 77 text
Links DE
• Podcast https://www.heise.de/developer/artikel/Episode-73-Technische-
Schulden-4771190.html
• Blog „Technische Schulden entstehen einfach so“
https://www.heise.de/developer/artikel/Technische-Schulden-entstehen-
einfach-so-3969279.html
• Artikel über Qualitätsinvestitonen mit Felix Müller – DE https://www.sigs-
datacom.de/fachzeitschriften/objektspektrum/archiv/artikelansicht/artikel-
titel/qualitaetsinvestitionen-statt-technischer-schuldenwarum-wir-eine-
neue-metapher-benoetigen.html
• Artikel Umgang mit technischen Schulden https://jaxenter.de/der-umgang-
mit-technischen-schulden-2548
Slide 78
Slide 78 text
DE Software Architektur im Stream
•Technische Schulden https://software-
architektur.tv/2021/02/05/folge37.html
•André Neubauer - CTO = Chief Technical Debt Owner?
https://software-architektur.tv/2021/01/15/folge35.html
•Qualitätsszenarien https://software-
architektur.tv/2021/07/16/folge67.html
•Patterns zu u.a. Refactoring https://software-
architektur.tv/2020/12/18/folge033.html