Technical Debt

Credit Crunch Code
Paying Back the Technical Debt
By Gary Short
1

Agenda
Defining Technical Debt
Why Managing Technical Debt is Important
Quantifying Technical Debt
Technical Debt Anti-Patterns & Fixes
Finding Technical Debt Using Metrics
Summary
Further Reading
Questions.
2

Defining Technical Debt #1
Term coined by Ward Cunningham in 1992
Analogous to financial debt
Financial debt = borrow money against a future date
Technical debt = borrow time against a future date.
3

Defining Technical Debt #2
With financial debt
“Virtual debt” by not having the best interest rate
With Technical Debt
Not making savings against time where possible.
4

Is There Interest On Technical Debt?
Just as there is interest on financial debt...
So there is interest on technical debt too:
Cost later – cost now
Financial value of damage to your brand
Loss of market share
Low staff morale.
5

Just As Not All Financial Debt Is Bad
6

Nor Is All Technical Debt
7

But Financial Debt Can Be Dangerous
8

And So Can Technical Debt
9

Why Is Managing Technical Debt Important?
10

Reduce Effort by Keeping it Under Control
11

Quantifying Technical Debt
12

Basic Formula To Get You Started
Where:
T = Total number of employees involved in paying back the debt
i = The individual employee
HRi = Hourly rate of pay for that individual
Hi = The hours that an individual worked in paying back the debt
EOC = Employer’s on cost – estimated at 40% of salary = 140% of salary
HP = Purchase cost of any hardware required
HI = Installation cost of any hardware required
SL= Cost of any software licences
X/Bba = An estimate of the damage to brand image.
13

Rate Card
Project Manager = 32 Euros / hour
Architect = 33 Euros / hour
Lead Developer = 30 Euros / hour
Developer = 26 Euros / hour
Tester = 20 Euros / hour
Tech. Support = 15 Euros / hour
Business Analyst = 32 Euros / hour.
*Hourly rate = average annual salary / (52 – 5wks AL * 5 – 9 days PH * 8 hrs)
**UK hourly rate converted to Euros via Google
***Correct as of November ’09. YMMV 
14

Case Study #1
The Anti-Pattern: Waterfall Methodology
15

The Main Weakness of Waterfall
16

Where Does Change Come From?
17

Why is Change So Costly?
18

Why Is This Technical Debt?
Borrow time now, repay later
Take advantages now
Ease in analysing potential changes
Ease of coordinating large teams
Precise budgeting
Repay later
Extra cost of change.
19

Quantify the Technical Debt: Agile
Assume a small error caught during the “paper prototype” phase of an iteration
Resources deployed
Architect spends 1 hour fixing design
Tester spends 1/2 hour verifying the fix
Apply those figures to our formula and:
Cost of fixing the error = 60 Euros.
20

Quantify the Technical Debt: BDUF
Now the same error found in waterfall...
Resources deployed
Architect 1 hour fixing design
Developer spends 4 hours coding solution
Lead developer spends ½ hour peer review
Tester spends 2 hours verifying fix
Cost of fixing the error = 208 Euros
Value of the technical debt = 148 Euros.
21

Potential Cost Per Project
So the TD / defect = 148 Euros
The av. number of defects / project = 283*
Potential TD / project = 41,884 Euros.
*Source: Scan 2006 Benchmark (as of March 2008)
22

Fixing The Technical Debt
I’m not saying prefer Agile over Waterfall
I am saying:
Be aware of the impact that might have on TD
Think about how you are going to combat that:
Review earlier in the process where change is cheap
Ensure the SME has peer review
Regular, early checks on design vs coded solution
Don’t leave all testing to the last phase.
23

Case Study #2
The Anti – Pattern: Not Invented Here
24

Symptoms
Development team spend time developing software which is not core the problem they are trying to solve
Instead of buying in a third party solution
They justify this by saying things like:
It doesn’t work the way we need it to
It would take me as long to write as to learn API
The 3rd party may go bust
The code isn’t good enough quality.
25

Concrete Example
Developers for a national bank are tasked with creating a new MIS tool
They dedicate 1 developer full time to creating a charting component
This sucks in testing and PM time too
Charting component not core to task at hand
Spent 3 months getting nowhere
Before buying a charting component.
26

Savings against time not made
Chose to develop a component
Should have bought from a third party.
27

Quantifying The Technical Debt
The component was bought in the end:
Disregard the cost of the component
And the time spent learning the API
Resources deployed:
1 X developer 3 months
1 X tester 1.5 months
1 X lead developer 1 day
1 X PM 1 day
Cost of technical debt : 24,886 Euros
28

Identify non core functional aspects of project
For each of those:
Can a component be bought in to achieve it?
If so, buy it
If not
Does your enterprise allow open source?
If so use it
Beware of licence implications
Only after evaluating and discounting alternatives should you consider writing your own.
29

Case Study #3
Anti-Pattern: Code that plays together stays together
30

Symptoms
Let’s imagine a “Car” object
What properties should it have?
Make
Model
Colour
What behaviour should it have?
None!
It’s an inanimate object!
A “Car” will have things done to it by “actors”.
31

What Is The Problem?
32

Example of Class Pollution
Credit: Phil Winstanley (http://weblogs.asp.net/Plip/)
33

Borrowed time now
Simpler object graph
Repay later in cost of adding functionality.
34

Concrete Example
Online provider wants to be first to market
Ships service with monolithic object graph
Effort required to add new features grows
Development slows to a crawl
Management demand a fix.
35

Quantifying the Technical Debt
1 monthly iteration to fix this debt
Resources deployed:
5 X Developers
1 X lead developer
2 X testers
Apply these figures to our formula and:
Cost of technical debt: 44,800 Euros.
36

Understand that
Monolithic object graph has a limited lifespan
Prefer separation of concerns
If first to market is important
Understand the value of the technical debt accrued
Decide when the debt will be paid off
Decide if commercial gain outweighs cost of debt
Refactoring tools can reduce “interest” on debt.
37

Case Study #4
The Anti-Pattern: Sensitive Tests
38

Symptoms
Test which are sensitive to
Context
Interface
Data
Pass in one iteration
Fail in the next due to changes.
39

Borrowed time in the form of easy to write tests
Repay later in form of fixing sensitive tests.
40

Concrete Example
Tester testing code which uses data from development database
Developer adds new functionality
Shape of the database changes
Values in the database change
Previously passing tests fail
Tests rewritten using current dev. database.
41

Quantifying the Technical Debt
Take previous 283 defects per project
Assume 10% of tests for those defects are data dependant
Assume it takes tester 30 minutes to fix each test
28 * 0.5 = 14 hours
Technical debt = 392 Euros.
42

Test must use independent data
Don’t run tests against development data
Either
Have a dedicated test database
Or it may be possible to mock data access
Or have the set up code for each test or suite of tests generate the data it requires and drop it during the tear down code.
43

How Do We Spot Technical Debt?
44

We Are Used to Charting Progress
45

Time Budget Failures Are Obvious
46

Effect #1 – Loss of Productivity
47

Effect #1 – Loss of Productivity
48

Effect #2 – Increase In Testing
49

Effect #2 – Increase In Testing
50

Effect #3 – Decrease In Morale
51

Effect #3 – Decrease In Morale
52

Summary
In this presentation you learned:
What technical debt is
That it is important to manage technical debt
Some common anti-patterns and how to fix them
Metrics to spot hidden technical debt
How to quantify technical debt.
53

Take Away
If you only take away one thing
Know that technical debt is
the silent killer that stalks all projects
Don’t let it kill your projects!
54

Further Reading
http://c2.com/cgi/wiki?WardExplainsDebtMetaphor
http://c2.com/cgi/wiki?TechnicalDebt
http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
http://www.martinfowler.com/bliki/TechnicalDebt.html
55

Questions?
There wasn’t time for my question
Where can I contact you?
gary@garyshort.org
www.garyshort.org
On Twitter as @garyshort.
56

http://www.mindgravy.net	80
http://www.slideshare.net	16
http://www.ontechnicaldebt.com	12
http://www.mybyte.co.za	1

Technical Debt

by Gary Short on Jan 25, 2010

Accessibility

Categories

Tags

Upload Details

Usage Rights

4 Embeds 109

Statistics

Technical Debt — Presentation Transcript