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
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
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
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
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
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
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
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
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
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
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
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
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