This document discusses technical debt and strategies for managing and selling technical debt rearchitecture projects. It defines technical debt as work that is postponed to a later time, such as lack of testing or architecture planning. While some debt can be useful for time to market goals, ignoring debt accumulation can slow a project over time. The document provides examples of technical debt elements to examine in a codebase and recommends conducting due diligence to understand existing debt. It also presents stories and metaphors to help explain the risks of debt to business stakeholders and the value of rearchitecture projects when needed.
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
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
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
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
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