Your SlideShare is downloading. ×
Technical Debt and Selling Rearchitecture
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Technical Debt and Selling Rearchitecture

387
views

Published on

This is a presentation that covers origins of technical debt, how to deal with it and how to "sell it" management

This is a presentation that covers origins of technical debt, how to deal with it and how to "sell it" management


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
387
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Technical Debt and Selling Rearchitecture 1 SERGEY SUNDUKOVSKIY PH.D.
  • 2. Introduction 2
  • 3. Agenda 3
  • 4. Technical Debt 4 Things slow down
  • 5. Debt 5 Everything you want to do “Later” is DEBT Let’s document later  Let’s test later  Let’s architect later  Let’s refactor later  Debt Misconceptions All debt is bad  No debt is great  Taking on debt always gets you there faster 
  • 6. Debt (Leverageable) 6
  • 7. Leveraging Debt 7 Debt Leverage 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  Unacceptable Debt Non-leveragable debt  Debt due to ignorance 
  • 8. Technical Debt Elements 8 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 
  • 9. Selling Debt Management 9
  • 10. Only If You Must 10 Debt Management 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 
  • 11. Only If You Must (cont.) 11 If You Can Help It, Do Not Sell It Schedule feature holidays (every 5th release)  Refactor as you go  Make debt management as part of the process  Give estimates considering debt management  Invite outside experts  If You Must Sell It Tell CEO/CTO story  Use aircraft maintenance strategy 
  • 12. Debt Story 12 I have not seen organs like this
  • 13. Common Story 13 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 
  • 14. Common Story 14 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 
  • 15. Support to Innovation Ratio 15 Year 1 Year 2 Year 3 Support (15%) Innovation (85%) Support (50%) Support (85%) Innovation (50%) Innovation (15%) Support cost is a euphemism for debt
  • 16. Debt Creeps Up on You 16 Yup it is kind of like that
  • 17. Broken Window Theory 17 One broken window leads to ruin
  • 18. Broken Window Theory 18 Do sweat the small stuff
  • 19. Due Diligence 19 Due Diligence is a an exercise of debt discovery
  • 20. Case Study 1 (Sample Due Diligence) 20 No Middle Tier Frameworks Code Entanglement Lots of Dead Code Poor Exception Handling High Coupling Low Encapsulation Absence of Higher Order Services Lack of Documented Architectural Blueprint
  • 21. Case Study 1 (Sample Due Diligence) 21 What does this mean? Increased Maintenance Cost  Difficulty Extending  Difficulty Hiring  Developer Lock In  Technical “Debt” That Needs To Be Repaid  Debt quantification  $200K
  • 22. Case Study 1 (Recommendations) 22 Refactor dead code Refactor code entanglement Refactor logic segmentation Introduce architectural blueprint Introduce unit, integration and functional tests Introduce persistence and decency injection frameworks Implement CIA/CEO principles
  • 23. Case Study 2 (Rearchitecture) 23 Sold It as a Project, Failed to Complete Political “hot” potato  No interim deliverable  Very expensive  Affected by business downturn 