Forget technical debt

This slide deck takes a broader look at the topic of technical debt. It starts with a brief look at why software engineers care about technical debt and what it is. Then it observes that commonly accepted criteria to measure technical debt do not exist which leads to a reexamination of the topic from first principles.

Starting with technical debt, the question what technical debt drives and what drives technical debt are asked, eventually resulting in a quite big graph that makes clear that looking at technical debt in isolation is not sufficient. It also makes clear that tackling other influencing factor will affect technical debt stronger than tackling technical debt itself.

The second part of the slide deck discusses 5+1 ideas how to tackle other influencing factors in order to eventually reduce technical debt.

Of course, the voice track is missing. Nevertheless, I hope the slides provide a few ideas to ponder.

Transcript

1. Forget technical debt Why looking at technical debt alone is not enough Uwe Friedrichsen – codecentric AG – 2010-2026
2. Uwe Friedrichsen Works @ codecentric https://bsky.app/profile/ufried.bsky.social https://www.speakerdeck.com/ufried https://ufried.com/blog/forget_technical_debt/
3. Why do we care about technical debt?
4. Technical debt • Makes developer lives harder • Code harder to understand • Code changes • take longer • are more expensive • are more error prone • Leads to loss of maintainability in the worst case
5. Comprehension of technical debt • Poorly understood outside of software development • Software usually confused with physical goods • Only production costs considered, not evolution costs * • Typically ignored outside of software development • Technical debt grows due to poor decision making • Harms reputation of software development • Leads to reinforcing cycle * Meir M. Lehman, "Programs, Life Cycles, and Laws of Software Evolution", 1980
6. We are interested in reducing technical debt
7. What is technical debt?
8. “Technical debt is a qualitative description of the cost to maintain a system that is attributable to choosing an expedient solution for its development.” — Wikipedia https://en.wikipedia.org/wiki/Technical_debt
9. “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... The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation [...]” — Ward Cunningham The WyCash Portfolio Management System , https://c2.com/doc/oopsla92.html
10. “As an evolving program is continually changed, its complexity, reflecting deteriorating structure, increases unless work is done to maintain or reduce it.” — Meir M. Lehman "Programs, Life Cycles, and Laws of Software Evolution", IEEE, 1980
11. How can we measure technical debt?
12. No clear criteria available
13. Measuring technical debt • No clear criteria available • Results in heated debates often based on personal taste • Often, system complexity measured as proxy metric • However, complexity and debt are not necessarily related • System age can be used as very rough indicator • Can be refined, e.g., via system size and technology • Avoid the imagined precision trap
14. What have we learned so far?
15. Insights • Technical debt • Relevant topic • Big driver of problems in IT • Poorly understood • No clear way to visualize available
16. Meh!
17. Rethinking technical debt from first principles
18. "What do we want to achieve by reducing technical debt?" Q
19. "We want to reduce a developer's cognitive load." A
20. Technical Debt Cognitive Load drives
21. "Why are we interested in reducing a developer’s cognitive load?" Q
22. A • “At development time, we want to keep the effort needed to implement a given requirement as small as possible.” (reduce overall development cost and time) • “At runtime, we want to minimize the number of issues and failures due to bugs in the software.” (increase overall system runtime availability)
23. Insights • Primary goals of reducing technical debt • Avoid implementation effort creep • Avoid runtime stability deterioration • Both are cumulative, long-term effects
24. Technical Debt Cognitive Load Implementation effort creep Runtime stability deterioration drives
25. Let us look in the opposite direction
26. " What drives implementation effort creep?" Q
27. A • Ignorant planning • Poorly written requirements • Poor development platform support • Meeting mania • Frequent context switches • Frequently changing requirements (“moving target”) • System crammed with useless requirements • Overly complex architectures • Overly complex processes • Overly rigid compliance demands • Lack of training and education for developers • Micromanaging managers, preventing any flow • Increased cognitive load • ...
28. Implementation effort creep drives Ignorant planning Poor requirements Poor development platform support Meeting mania Frequent developer context switches Continuous requirement changes System crammed with unneeded requirements Overly complex processes Overly complex architectures Overly rigid compliance demands Micromanaging managers Lack of training and education of developers … Cognitive Load
29. " What drives runtime stability deterioration?" Q
30. A • Understaffed operations department • Outdated platform and infrastructure software versions • Undertrained administrators • Poor monitoring • Overly complex, incoherent tech stack • Manual deployment and administration processes • Overly rigid compliance demands • Cognitive load (resulting in more software bugs) • ...
31. Runtime stability deterioration Cognitive Load (resulting in more software bugs) Understaffed operations department Outdated software versions Undertrained administrators Poor monitoring Overly complex, incoherent tech stack Manual processes Overly rigid compliance demands … drives
32. " What drives cognitive load?" Q
33. A • Wasteful business requirements • Stress • Overly complex rules and regulations • DevOps gone wrong • ...
34. Cognitive Load Technical Debt Wasteful business requirements Stress Overly complex rules/processes DevOps gone wrong … drives
35. Implementation effort creep drives Runtime stability deterioration Cognitive Load Poor requirements Poor development platform support Meeting mania Frequent developer context switches Continuous requirement changes System crammed with unneeded requirements Overly complex processes Overly complex architectures Overly rigid compliance demands Micromanaging managers Lack of training and education of developers … Understaffed operations department Outdated software versions Undertrained administrators Poor monitoring Overly complex, incoherent tech stack Manual processes Overly rigid compliance demands … DevOps gone wrong Wasteful business requirements Stress Overly complex rules/processes Technical Debt … Ignorant planning Could all be broken down further
36. " What drives technical debt?" Q
37. A • Everything that drives implementation effort creep • Everything that drives developer overload (often caused by the other drivers) • Extremely tight deadlines • Overstuffed development increments • Lack of time to document or share relevant information between development team members • ...
38. Cognitive Load Implementation effort creep Poor requirements Poor development platform support Meeting mania Frequent developer context switches Continuous requirement changes System crammed with unneeded requirements Overly complex processes Overly complex architectures Overly rigid compliance demands Micromanaging managers Lack of training and education of developers … drives Runtime stability deterioration Understaffed operations department Outdated software versions Undertrained administrators Poor monitoring Overly complex, incoherent tech stack Manual processes Overly rigid compliance demands … DevOps gone wrong Wasteful business requirements Stress Overly complex rules/processes Technical Debt … Developer overload Extremely tight deadlines Overstuffed increments No time for sharing No time for documentation ... Ignorant planning drives indirectly
39. Insights • Technical debt is just a piece of a much bigger picture • The overarching goals are to reduce • Implementation effort creep • Runtime stability deterioration • Many drivers directly or indirectly affect technical debt à Looking at technical debt alone is not enough
40. Why do we limit our perception?
41. Reasons for limited perception * • Technical debt immediately affects us negatively • We immediately experience it • Level of indirection between other drivers and our work • Other drivers may feel like being outside of our influence • We know how to tackle technical debt • With other drivers, we often do not know * A subjective guess
42. What can we do to improve our situation?
43. Improving the situation • Help people understand software • Often confused with a physical good • Results in sole focus on production costs • Results in broken assembly line analogies • Invisibility of software as aggravating factor * • Teach the “Laws of Software Evolution” ** * Frederick P. Brooks, “No Silver Bullet”, 1986 ** Meir M. Lehman, "Programs, Life Cycles, and Laws of Software Evolution", 1980
44. Improving the situation • Help people understand software • Fight meeting mania
45. Meeting mania • Everybody is sitting in meetings all day • Information flow still does not work • More meetings are scheduled
46. Why do you think more meetings would improve the situation?
47. Improving the situation • Help people understand software • Fight meeting mania • Find better ways to share information and make decisions • Make remaining meetings more effective • Fight for uninterrupted deep work time (at least 50% of time)
48. Improving the situation • Help people understand software • Fight meeting mania • Go for hypothesis-driven development
49. Companies are obsessed with efficiency
50. "Efficiency is the ability to do things well, successfully, and without waste.” — https://en.wikipedia.org/wiki/Efficiency
51. More is better!
52. Business value is implicitly assumed
53. Value-adding performance Idle performance Value-reducing performance Companies continually measuring outcome 20% 40% 40% Best in class companies 33% 33% 33% Average company ~10% ~ 50% ~ 40% ∅
54. Expected value does not manifest Shotgun implementation We need more features! Implementation must become faster! (a.k.a. more efficiency)
55. Consequences • Huge waste of money and efforts • Massive developer burnout rates • Exploding system complexity • Exploding technical debt • Deteriorating system quality and dependability • Everyone else unsatisfied and stressed, too
56. Our biggest challenge in IT is a lack of effectiveness, not a lack of efficiency. Software development, especially coding is extremely efficient.
57. "Effectiveness is the capability of producing a desired result.” — https://en.wikipedia.org/wiki/Effectiveness
58. Effectiveness is about doing the right thing. Efficiency is about doing the thing right.
59. Our problem is not that we do not create enough software. We create way more software than we need. But most software created is just waste.
60. How (not) to improve effectiveness
61. Imagine you have an idea and EUR 1 million budget How do you spend it best?
62. Specify idea (poorly) in detail * Mind Wegner’s Lemma: "It is impossible to fully specify or test an interactive system designed to respond to external inputs." The traditional way Insist in complete implementation Complain about exceeding budget Blame developers Release after completed See what happens Claim the glory Successful (~10% chance) Not successful (~90% chance) Hush it up or blame someone else Increase pressure on developers Continuously adjust requirements *
63. Taking it further …
64. Imagine you have 10 ideas and EUR 10 million budget Where do you end up following the traditional way?
65. Effects of the traditional way • > EUR 10 Mio spent (plus lots of time and well-being) • 1 valuable feature • Added accidental complexity from 9 worthless features • Future implementations will be • Slower • More expensive • More error-prone
66. That does not look worthwhile
67. Let us try a different hypothesis-driven approach
68. Let us split up the idea in a series of small questions (hypotheses) … … and validate the users’ feedback for each hypothesis before moving on …
69. The alternative hypothesis-driven way Hypothesis confirmed? Implement and deploy with minimal effort No Pivot? Choose next most significant hypothesis Measure users’ feedback Adjust idea and hypotheses Yes Done? Yes No Break idea down in small hypotheses Remaining * No Remaining Yes * Usually, you already start making revenue while still validating the idea
70. Taking it further …
71. Imagine you have 10 ideas and EUR 10 million budget Where do you end up following the alternative way?
72. Assumptions • Unsuccessful ideas discarded after spending 1/10 of budget • Revenue made while validating ideas not considered
73. Effects of the alternative way (1/2) • < EUR 2 Mio spent (> 80% budget saved) • 1 valuable feature (unchanged) • 80% less developer capacity needed • Massively reduced burnout rate • Invest in higher dependability and sustainability • Powerful mitigation of skills shortage problem
74. Effects of the alternative way (2/2) • No accidental complexity from 9 worthless features added • Less code • Less complexity • Future implementations will be • Faster • Less expensive • Less error-prone
75. Improving the situation • Help people understand software • Fight meeting mania • Go for hypothesis-driven development • One of the biggest levers available • Can even lead to “technical credit” • Requires buy-in of the product managers • Start with automation to minimize IT lead times • Start to measure business value of features
76. Improving the situation • Help people understand software • Fight meeting mania • Go for hypothesis-driven development • Fight for simplicity • Architecture • Implementation • Platform
77. Mind the complexity bias • Beware the “cult of complex” • Apply Occam's razor
78. Improving the situation • Help people understand software • Fight meeting mania • Go for hypothesis-driven development • Fight for simplicity • Invest in automation • Reduces cognitive load • Reduces probability of getting something wrong
79. Improving the situation • Help people understand software • Fight meeting mania • Go for hypothesis-driven development • Fight for simplicity • Invest in automation • Embrace boring technology
80. Do not try to change everything at once
81. Embrace Atomic Habits
82. Improve the situation one step at a time
84. Build a starter toolbox for change management
85. Wrap-up
86. Wrap-up • Technical debt hurts developers and companies • Poorly understood outside development, hence ignored • Looking at technical debt alone is not enough • Act on other drivers to improve the situation • Mind the "atomic habits"
87. A journey of a thousand miles begins with a single step -- Chinese proverb
88. Uwe Friedrichsen Works @ codecentric https://bsky.app/profile/ufried.bsky.social https://www.speakerdeck.com/ufried https://ufried.com/blog/forget_technical_debt/