Credit Crunch Code<br />Paying Back
the Technical Debt<br />By Gary Short<br />1<br />

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

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

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

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

Just As Not All Financial
Debt Is Bad<br />6<br />

Nor Is All Technical Debt<br
/>7<br />

But Financial Debt Can Be
Dangerous<br />8<br />

And So Can Technical Debt<br
/>9<br />

Why Is Managing Technical Debt
Important?<br />10<br />

Reduce Effort by Keeping it
Under Control<br />11<br />

Quantifying Technical Debt<br />12<br />

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

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

Case Study #1<br />The Anti-Pattern:
Waterfall Methodology<br />15<br />

The Main Weakness of Waterfall<br
/>16<br />

Where Does Change Come From?<br
/>17<br />

Why is Change So Costly?<br
/>18<br />

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

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

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

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

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

Case Study #2<br />The Anti
– Pattern: Not Invented Here<br />24<br />

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

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

Why Is This Technical Debt?<br
/>Savings against time not made<br />Chose to develop a component<br />Should have bought from a third party.<br />27<br />

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

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

Case Study #3<br />Anti-Pattern: Code
that plays together stays together<br />30<br />

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

What Is The Problem?<br />32<br
/>

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

Why Is This Technical Debt?<br
/>Borrow time now, repay later<br />Borrowed time now<br />Simpler object graph<br />Repay later in cost of adding functionality.<br />34<br />

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

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

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

Case Study #4<br />The Anti-Pattern:
Sensitive Tests<br />38<br />

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

Why Is This Technical Debt?<br
/>Borrow time now, repay later<br />Borrowed time in the form of easy to write tests<br />Repay later in form of fixing sensitive tests.<br />40<br />

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

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

Fixing The Technical Debt<br />Test
must use independent data<br />Don’t run tests against development data<br />Either<br />Have a dedicated test database<br />Or it may be possible to mock data access <br />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.<br />43<br />

How Do We Spot Technical
Debt?<br />44<br />

We Are Used to Charting
Progress<br />45<br />

Time Budget Failures Are Obvious<br
/>46<br />

Effect #1 – Loss of
Productivity<br />47<br />

Effect #1 – Loss of
Productivity<br />48<br />

Effect #2 – Increase In
Testing<br />49<br />

Effect #2 – Increase In
Testing<br />50<br />

Effect #3 – Decrease In
Morale<br />51<br />

Effect #3 – Decrease In
Morale<br />52<br />

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

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

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

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