Technical & Product Debt Management
-
Upload
sergey-sundukovskiy -
Category
Technology
-
view
486 -
download
2
Transcript of Technical & Product Debt Management
Technical & Product Debt ManagementBy Dr. Sergey Sundukovskiy
Introduction
Sergey Sundukovskiy, Ph.D.Head of Engineering - Technology Innovation at Capital OneCurrent: Capital One, Google, 500 Startups Previous: Launchpad LA, PushPoint, LivnGiv
“… A design or construction approach that is expedient in the short term but that creates a technical context in which the same work will cost more to do later than it would cost to do now (including increased cost over time).”
3
Debt
Everything You Want to Do “Later” Is DEBT• Let’s Document Later• Let’s Test Later• Let’s Architect Later• Let’s Refactor Later
4
Debt
Technical Debt Results
Product
Debt
Things SLOW DOWN
• All Debt Is Bad• No Debt Is Great • Taking On Debt Always Gets You There Faster
6
Debt Misconceptions
Technical Debt Story
I Have Not Seen Organs Like These
CEOs Tale• We were very productive• We kicked ass• 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
8
Common Story
CTOs Tale• We were very productive through debt accumulation• We kicked ass but burned out• We slowed down due to increasing debt support• We got fired• New team got hired• It does not know where skeletons are buried• We got fired as well• I have Not Seen Organs Like These
9
Common Story
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
Leveraging DebtContinued
• Time to Market – If taking on debt gets you to market disproportionately faster
• Time to Contact – 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
• Non-Leveragable Debt• Debt Due to Ignorance• Debt Due to Laziness
Unacceptable Debt
Technical Debt Survey
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
How Did We Let It Happen?
One Logical Step at a Time
Broken Window Theory
One Broken Window Leads to Ruin
Broken Window Theory
Do Sweat the Small Stuff
Small VandalismUrban Decay
CRIME
Debt Tipping Point
Product Death
Year 2
Year 1
Tipping Point
Debt Creeps Up on You
Yup, It is Kind of Like That
No Turning Back Now!
The Snowball Effect
SPLAT!
Debt Management
Regular, Slow and Steady Does It
Technical Debt ManagementTechnology 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
Product Debt
Yup, That’s Feature Creep
Featuritis Curve
Number of Features
Use
r H
appi
ness 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!”
Features Usage
What is Product Debt?
Product Debt = Product Complexity = User Confusion
Multiplicative Complexity
N(N-1)/2 – Undirected Graph N(N-1) – Directed Graph
Ease of Use
Main Feature = Easy to Use
Irreducible Complexity
Simplest Mousetrap
Product Feature AttributesIntelligent Design and Evolutionary Concepts
• Aim For Adjacent Possible
Irreducible Complexity• Can’t Take Anything Away• Can’t Be Simpler
Simplest for What It Does• Simple Path to Intent
31
Path to Intent
Straightforward Path to Intent
Feature PaymentsFeature Currency
• Confusion “Payment” for Features
What Do They Mean?• “This Is Confusing”
Ideal Feature• Minimal Confusion• Minimal Multiplicative Complexity
33
Features
Conf
usio
n
Ideal Balance
Realistic Balance
Feature Payments
• Do Not Complicate Things• Do Not Make Users Think• Do Not Make Users Work• Do Not Defy User’s Expectations• Do Not Confuse Yourself With Users• Do Not Assume You Know Everything
34
Product Debt Don’ts
35
Always Be Testing
36
Painted Door
Painted Door vs. Real Door
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
37
Product Debt Management
Not The Same Thing
Management
Mitigation
39
Selling Debt Mitigation
Debt Mitigation Is Very Hard To Sell• Cause and effect is not immediately apparent• ROI is very difficult to quantify• Definition of done is hard to come up with• Perpetual projects are not crowd pleasers• Users are not even aware that backend of apps
even exists. UX/UI in user’s mind is the app itself
40
Debt Mitigation Advice
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
41
Debt Mitigation AdviceContinued