Technical Debt and Selling
Rearchitecture
1
SERGEY SUNDUKOVSKIY PH.D.
Introduction
2
Agenda
3
Technical Debt
4

Things slow down
Debt
5

Everything you want to do “Later” is DEBT
Let’s document later
 Let’s test later
 Let’s architect later
 Let’s...
Debt (Leverageable)
6
Leveraging Debt
7

Debt Leverage
Time to market – If taking on debt gets you to market
disproportionately faster
 Time t...
Technical Debt Elements
8

Technical Debt Elements
Lack of Architectural Blueprint
 Lack of Unit Testing
 Lack of Integ...
Selling Debt Management
9
Only If You Must
10

Debt Management Is Very Hard To Sell
Cause and effect is not immediately apparent
 ROI is very diff...
Only If You Must (cont.)
11

If You Can Help It, Do Not Sell It
Schedule feature holidays (every 5th release)
 Refactor ...
Debt Story
12

I have not seen organs like this
Common Story
13

CEOs Tale
We were very productive
 We kicked ass
 We became complacent
 I fired them all
 I hired a ...
Common Story
14

CTOs Tale
We were very productive through debt accumulation
 We kicked ass but burned out
 We slowed d...
Support to Innovation Ratio
15

Year 1
Year 2
Year 3

Support
(15%)

Innovation
(85%)

Support
(50%)
Support
(85%)

Innova...
Debt Creeps Up on You
16

Yup it is kind of like that
Broken Window Theory
17

One broken window leads to ruin
Broken Window Theory
18

Do sweat the small stuff
Due Diligence
19

Due Diligence is a an exercise of debt discovery
Case Study 1 (Sample Due Diligence)
20

No Middle Tier Frameworks
Code Entanglement
Lots of Dead Code
Poor Exception H...
Case Study 1 (Sample Due Diligence)
21

What does this mean?
Increased Maintenance Cost
 Difficulty Extending
 Difficul...
Case Study 1 (Recommendations)
22

Refactor dead code
Refactor code entanglement
Refactor logic segmentation
Introduce...
Case Study 2 (Rearchitecture)
23

Sold It as a Project, Failed to Complete
Political “hot” potato
 No interim deliverabl...
Upcoming SlideShare
Loading in...5
×

Technical Debt and Selling Rearchitecture

456

Published on

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

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
456
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Technical Debt and Selling Rearchitecture

  1. 1. Technical Debt and Selling Rearchitecture 1 SERGEY SUNDUKOVSKIY PH.D.
  2. 2. Introduction 2
  3. 3. Agenda 3
  4. 4. Technical Debt 4 Things slow down
  5. 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. 6. Debt (Leverageable) 6
  7. 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. 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. 9. Selling Debt Management 9
  10. 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. 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. 12. Debt Story 12 I have not seen organs like this
  13. 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. 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. 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. 16. Debt Creeps Up on You 16 Yup it is kind of like that
  17. 17. Broken Window Theory 17 One broken window leads to ruin
  18. 18. Broken Window Theory 18 Do sweat the small stuff
  19. 19. Due Diligence 19 Due Diligence is a an exercise of debt discovery
  20. 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. 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. 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. 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 
  1. ¿Le ha llamado la atención una diapositiva en particular?

    Recortar diapositivas es una manera útil de recopilar información importante para consultarla más tarde.

×