Downloaded 83 times
Uploaded bySergey Sundukovskiy
Technical & Product Debt Management
The document by Dr. Sergey Sundukovskiy discusses the concepts of technical and product debt, emphasizing that while some debt may allow for quicker market entry, it can ultimately slow down productivity and create complications over time. It outlines strategies for effective debt management and emphasizes the importance of maintaining a balance between innovation and support to prevent accumulating unsustainable debt. Additionally, the document addresses misconceptions around debt, the implications of product complexity, and the need for continuous testing and user feedback in product development.
More Related Content
Similar to Technical & Product Debt Management
Technical & Product Debt Management
- 1. Technical & Product DebtManagement By Dr. Sergey Sundukovskiy
- 2. Introduction Sergey Sundukovskiy, Ph.D. Head of Engineering- Technology Innovation at Capital One Current: Capital One, Google, 500 Startups Previous: Launchpad LA, PushPoint, LivnGiv
- 3. “… A designor 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
- 4. Everything You Wantto Do “Later” Is DEBT • Let’s Document Later • Let’s Test Later • Let’s Architect Later • Let’s Refactor Later 4 Debt
- 5.
- 6. • All DebtIs Bad • No Debt Is Great • Taking On Debt Always Gets You There Faster 6 Debt Misconceptions
- 7. Technical Debt Story IHave Not Seen Organs Like These
- 8. CEOs Tale • Wewere 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
- 9. CTOs Tale • Wewere 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
- 10. Support Cost isa 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. • Time toMarket – 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
- 13. • Non-Leveragable Debt •Debt Due to Ignorance • Debt Due to Laziness Unacceptable Debt
- 14.
- 15. 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
- 16. How Did WeLet It Happen? One Logical Step at a Time
- 17. Broken Window Theory OneBroken Window Leads to Ruin
- 18. Broken Window Theory DoSweat the Small Stuff Small Vandalism Urban Decay CRIME
- 19. Debt Tipping Point ProductDeath Year 2 Year 1 Tipping Point
- 20. Debt Creeps Upon You Yup, It is Kind of Like That No Turning Back Now! The Snowball Effect SPLAT!
- 21. Debt Management Regular, Slowand Steady Does It
- 22. Technical Debt Management TechnologyDebt 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
- 23. Product Debt Yup, That’sFeature Creep
- 24. Featuritis Curve Number ofFeatures UserHappiness 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!”
- 25.
- 26. What is ProductDebt? Product Debt = Product Complexity = User Confusion
- 27. Multiplicative Complexity N(N-1)/2 –Undirected Graph N(N-1) – Directed Graph
- 28. Ease of Use MainFeature = Easy to Use
- 29.
- 30. Product Feature Attributes IntelligentDesign 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. 31 Path to Intent StraightforwardPath to Intent
- 32. Feature Payments Feature Currency •Confusion “Payment” for Features What Do They Mean? • “This Is Confusing” Ideal Feature • Minimal Confusion • Minimal Multiplicative Complexity
- 33.
- 34. • Do NotComplicate 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.
- 36. 36 Painted Door Painted Doorvs. Real Door
- 37. Product Debt Managementand 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
- 38. Not The SameThing Management Mitigation
- 39.
- 40. Debt Mitigation IsVery 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
- 41. If You CanHelp 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 Advice Continued