Technical Debt is a gap between Computer Science and Software Engineering. Common understanding of causes for the Technical Debt is centered on the careless software development choices for the sake of speed and expediency. However Technical Debt usually goes beyond just Technology. This presentation covers the origins of Technical and Product Debt, how to manage it and mitigate it

1. Technical & Product
Debt Management
By Dr. Sergey Sundukovskiy
1

2. Introduction
SergeySundukovskiy, Ph.D.
Co-Founder, CPO/CTO – Salesmsg
2

3. Point of Origin
3

4. “… Adesign or construction approach that is expedient in theshort term but that creates a technical
context inwhich the same workwill cost moreto do laterthan it would cost to do now (including
increased cost over time).”
4
Debt

5. EverythingYouWant toDo “Later” Is DEBT
• Let’s Document Later
• Let’s Test Later
• Let’s Architect Later
• Let’s Refactor Later
5
Debt

6. Technical Debt Results
Product
Debt
ThingsSLOW DOWN
6

7. • All Debt Is Bad
• No Debt Is Great
• Taking On Debt Always Gets You There Faster
7
Debt Misconceptions

8. Technical Debt Story
I Have Not Seen Organs Like These
8

9. CEOs Tale
• We were very productive
• We kicked butt
• We became complacent
• I fired them all
• I hired a new team
• They are not productive either
• Must have chosen wrong
• I fired them all
• SAVE ME
9
Common Story

10. CTOs Tale
• We were very productive through debt accumulation
• We kicked butt but burned out
• We slowed down due to increasing debt support
• We got fired
• New team got hired
• They does not know where bodies are buried
• They got fired as well
• I have Not Seen Organs Like These
10
Common Story

11. Support Cost is a Euphemism for Debt
Support
(15%)
Innovation
(85%)
Support
(50%)
Innovation
(50%)
Support
(85%)
Innovation
(15%)
Year 1
Year 2
Year 3
Support to Innovation Ratio
11

12. Leveraging Debt
Continued
12

13. Known Cost for Known Benefit
• Time to Market – If taking on debt gets you to market disproportionately
faster
• Time to Contract – If strategic contract is at stake debt might be worth it
• Time to Funding – If funding is at stake debt might be worth it
• Time to Survival – Debt is irrelevant if there is no tomorrow
Leveraging Debt
13

14. Unknown Cost for Unknown Benefit
• Unintentional – This Module Is Just a Temporary Fix
• Unquantified – If We Develop This Feature Many New Customers Will
Buy the Product
• Unplanned – This Code Is Simple. We Do Not Need to Document It
• Inadvertent – We Were Not Aware This Library Has a Particular Side
Effect
• Reckless – This New Framework Looks Very Interesting, Let’s Use It in
Production
Leveraging Debt
14

15. Technical Debt Survey
15

16. Technical Debt Elements
• Lack of Architectural Blueprint
• Lack of Unit Testing
• Lack of Integration Testing
• Lack of Code Reviews
• Lack of Starter Platform
• Lack of Starter Framework
• Lack of Technical Design
• Lack of Development Recipes
• Lack of Design Process
16

17. How Did We Let It Happen?
One Logical Debt Step at a Time
17

18. Broken Window Theory
One Broken Window Leads to Ruin
18

19. Broken Window Theory
Do Sweat the Small Stuff
Small Vandalism
Urban Decay
CRIME
19

20. Debt Tipping Point
Product Death
Year 2
Year 1
Tipping Point
20

21. Debt Creeps Up on You
Yup, It is Kind of Like That
No Turning Back
Now!
The Snowball Effect
SPLAT!
21

22. Technical Debt Management
Technology Debt Management and Debt
Avoidance
• Build on Top of IaaS/PaaS
• Build on Top of Starter Product/Starter Framework
• Implement Unit/Integration/Functional Testing
• Conduct Code Review
• Implement CI/CD/CD
• Establish Short Sprints (Agile) or No Sprints (Kanban)
• Non-Monolithic Design
22

23. Product Debt
Yup, That’s Feature Creep
23

24. Minimal Viable
Eric Ries defines MVP as “…thatversion of a new product which allows a team to
collect the maximum amount of validated learning about customers with the least
effort.”
Minimal
Product nobody
wants touse
Viable
Productbuilt
bycompanies
that have no
financial limitations
MVP
24

25. Ideal MVP
Core Functionality
• Same Major Features
• Same Major Functionality
• Same Usability
• Not UpTo Scale
• Not As Aesthetic
25

26. Difficult Product Determinations
Prototypevs. MVP
• How Do IDistinguish?
– MVPvs. MatureProduct
• At What Point Do IStop?
– Intent Matters
• YouWill Get What YouAreAimingFor
26

27. MVP vs. Prototype Purpose
MVP
• Test Product Viability
• Test Assumptions
• Test theMarket
• Test Product Usability
• Get User Feedback
Prototype
• Demonstrate the Product Concept
27

28. MVP vs. Prototype Targeting
PrototypeTargetsInnovators
MVPTargetsEarly Adopters
EarlyAdopter Groups
• Educators
• Influencers
• Opinion Makers
• Social Connectors
28

29. MVP vs. Prototype Development
MVP
• Built by a Minimal Viable Team
• Evolutionaryin Its Development
Prototype
• Built by One Person
• Usually Throwaway in Its Development
29

30. Ease of Use
Main Feature = Easy to Use
30

31. 31
Path to Intent
Straightforward Path to Intent

32. Irreducible Complexity
Simplest Mousetrap
32

33. Adjacent Possible Product
Your Product vs. Adjacent Possible Product
Existing Product
Your Product
33

34. Feature Debt Considerations
Intelligent Design and Evolutionary Concepts
• Aim For Adjacent Possible
IrreducibleComplexity
• Can’t TakeAnythingAway
• Can’t Be Simpler
Simplest for What It Does
• Simple Path to Intent
34

35. Product Debt Feature Curve
Number of Features
User
Happiness
Happy User Peak
“I rule!”
“Cool!”
“I’m so glad they
added this.”
“Nice, but I wish I
could do more…”
“Guess I better look at
the manual…”
“Hey, where the f***
did they put that?!”
“Now I can’t even do the ONE
SIMPLE THING I bought this
for…”
“I suck!”
35

36. Features Usage
36

37. What is Product Debt?
Product Debt = Product Complexity = User Confusion
37

38. Multiplicative Complexity
N(N-1)/2– Undirected Graph
N(N-1)– Directed Graph
38

39. Feature Payments
FeatureCurrency
• Confusion “Payment”for Features
What DoTheyMean?
• “This IsConfusing”
Ideal Feature
• Minimal Confusion
• Minimal Multiplicative Complexity
39

40. 40
Features
Confusion
Ideal Balance
Realistic Balance
Feature Payments

41. • Do Not ComplicateThings
• Do Not MakeUsers Think
• Do Not MakeUsers Work
• Do Not Defy User’s Expectations
• Do Not Confuse Yourself With Users
• Do Not Assume YouKnow Everything
41
Product Debt Don’ts

42. 42
Always Be Testing

43. Product Debt Management and Debt Avoidance
• 30% of the Sprint Should Be Devoted to Feature Removal
• Test Before You Implement
• Collect User Feedback
• Measure and Correlate Churn
• Assess Complexity and Confusion
43
Product Debt
Management

44. Not The Same Thing
Management Mitigation
44

45. 45
Selling Debt Mitigation

46. Debt Mitigation Is VeryHard ToSell
• Causeand effect is not immediately apparent
• ROI is verydifficult to quantify
• Definition of done is hardto come up with
• Perpetual projects are not crowd pleasers
• Users are not even aware that backend of apps even exists. UX/UIinuser’s mind is the
app itself
46
Debt Mitigation Advice

47. Debt Mitigation
Regular, Slow and Steady Does It
47

48. If You Can Help It, Do Not Sell It
• Schedule feature holidays (every 5th release)
• Refactor as you go
• Make debt mitigation as part of the process
• Give estimates considering debt mitigation
• Invite outside experts
If You Must Sell It
• Tell CEO/CTO story
• Use aircraft maintenance strategy
48
Debt Mitigation Advice
Continued