technical debt and selling rearchitecture

23
SERGEY SUNDUKOVSKIY PH.D. Technical Debt and Selling Rearchitecture 1

Upload: sergey-sundukovskiy

Post on 05-Dec-2014

566 views

Category:

Technology


0 download

DESCRIPTION

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

TRANSCRIPT

Page 1: Technical Debt and Selling Rearchitecture

SERGEY SUNDUKOVSKIY PH.D.

Technical Debt and Selling Rearchitecture

1

Page 2: Technical Debt and Selling Rearchitecture

Introduction2

Page 3: Technical Debt and Selling Rearchitecture

Agenda3

Page 4: Technical Debt and Selling Rearchitecture

Technical Debt

Things slow down

4

Page 5: Technical Debt and Selling Rearchitecture

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

Debt Misconceptions All debt is bad No debt is great Taking on debt always gets you there faster

5

Page 6: Technical Debt and Selling Rearchitecture

Debt (Leverageable)6

Page 7: Technical Debt and Selling Rearchitecture

Leveraging Debt

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

7

Page 8: Technical Debt and Selling Rearchitecture

Technical Debt Elements

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

8

Page 9: Technical Debt and Selling Rearchitecture

Selling Debt Management9

Page 10: Technical Debt and Selling Rearchitecture

Only If You Must

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

10

Page 11: Technical Debt and Selling Rearchitecture

Only If You Must (cont.)

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

11

Page 12: Technical Debt and Selling Rearchitecture

Debt Story

I have not seen organs like this

12

Page 13: Technical Debt and Selling Rearchitecture

Common Story

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

13

Page 14: Technical Debt and Selling Rearchitecture

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

14

Page 15: Technical Debt and Selling Rearchitecture

Support to Innovation Ratio

Support cost is a euphemism for debt

15

Support(15%)

Innovation(85%)

Support(50%)

Innovation(50%)

Support(85%)

Innovation(15%)

Year 1

Year 2

Year 3

Page 16: Technical Debt and Selling Rearchitecture

Debt Creeps Up on You

Yup it is kind of like that

16

Page 17: Technical Debt and Selling Rearchitecture

Broken Window Theory

One broken window leads to ruin

17

Page 18: Technical Debt and Selling Rearchitecture

Broken Window Theory

Do sweat the small stuff

18

Page 19: Technical Debt and Selling Rearchitecture

Due Diligence19

Due Diligence is a an exercise of debt discovery

Page 20: Technical Debt and Selling Rearchitecture

Case Study 1 (Sample Due Diligence)

No Middle Tier Frameworks Code EntanglementLots of Dead CodePoor Exception HandlingHigh CouplingLow EncapsulationAbsence of Higher Order ServicesLack of Documented Architectural Blueprint

20

Page 21: Technical Debt and Selling Rearchitecture

Case Study 1 (Sample Due Diligence)

What does this mean? Increased Maintenance Cost Difficulty Extending Difficulty Hiring Developer Lock In Technical “Debt” That Needs To Be Repaid

Debt quantification $200K

21

Page 22: Technical Debt and Selling Rearchitecture

Case Study 1 (Recommendations)

Refactor dead codeRefactor code entanglementRefactor logic segmentationIntroduce architectural blueprintIntroduce unit, integration and functional testsIntroduce persistence and decency injection frameworksImplement CIA/CEO principles

22

Page 23: Technical Debt and Selling Rearchitecture

Case Study 2 (Rearchitecture)

Sold It as a Project, Failed to Complete Political “hot” potato No interim deliverable Very expensive Affected by business downturn

23