Technical & Product Debt ManagementBy Dr. Sergey Sundukovskiy

Introduction

Sergey Sundukovskiy, Ph.D.Head of Engineering - Technology Innovation at Capital OneCurrent: Capital One, Google, 500 Startups Previous: Launchpad LA, PushPoint, LivnGiv

“… A design or 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

Everything You Want to Do “Later” Is DEBT• Let’s Document Later• Let’s Test Later• Let’s Architect Later• Let’s Refactor Later

4

Debt

Technical Debt Results

Product

Debt

Things SLOW DOWN

• All Debt Is Bad• No Debt Is Great • Taking On Debt Always Gets You There Faster

6

Debt Misconceptions

Technical Debt Story

I Have Not Seen Organs Like These

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

8

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

9

Common Story

Support Cost is a 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

Leveraging DebtContinued

• 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

Leveraging Debt

• Non-Leveragable Debt• Debt Due to Ignorance• Debt Due to Laziness

Unacceptable Debt

Technical Debt Survey

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

How Did We Let It Happen?

One Logical Step at a Time

Broken Window Theory

One Broken Window Leads to Ruin

Broken Window Theory

Do Sweat the Small Stuff

Small VandalismUrban Decay

CRIME

Debt Tipping Point

Product Death

Year 2

Year 1

Tipping Point

Debt Creeps Up on You

Yup, It is Kind of Like That

No Turning Back Now!

The Snowball Effect

SPLAT!

Debt Management

Regular, Slow and Steady Does It

Technical Debt ManagementTechnology Debt 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

Product Debt

Yup, That’s Feature Creep

Featuritis Curve

Number of Features

Use

r H

appi

ness 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!”

Features Usage

What is Product Debt?

Product Debt = Product Complexity = User Confusion

Multiplicative Complexity

N(N-1)/2 – Undirected Graph N(N-1) – Directed Graph

Ease of Use

Main Feature = Easy to Use

Irreducible Complexity

Simplest Mousetrap

Product Feature AttributesIntelligent Design 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

Path to Intent

Straightforward Path to Intent

Feature PaymentsFeature Currency

• Confusion “Payment” for Features

What Do They Mean?• “This Is Confusing”

Ideal Feature• Minimal Confusion• Minimal Multiplicative Complexity

33

Features

Conf

usio

n

Ideal Balance

Realistic Balance

Feature Payments

• Do Not Complicate 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

Always Be Testing

36

Painted Door

Painted Door vs. Real Door

Product Debt Management and 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

Not The Same Thing

Management

Mitigation

39

Selling Debt Mitigation

Debt Mitigation 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

40

Debt Mitigation Advice

If You Can Help 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 AdviceContinued