570 likes | 741 Views
Credit Crunch Code. Paying Back the Technical Debt By Gary Short. Agenda. Admin 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.
E N D
Credit Crunch Code Paying Back the Technical Debt By Gary Short
Agenda • Admin • 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.
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.
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.
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.
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
Case Study #1 • The Anti-Pattern: Waterfall Methodology
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.
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.
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 • Apply those figures to our formula and: • Cost of fixing the error = 208 Euros • Value of the technical debt = 148 Euros.
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)
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.
Case Study #2 • The Anti – Pattern: Not Invented Here
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.
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.
Why Is This Technical Debt? • Savings against time not made • Chose to develop a component • Should have bought from a third party.
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
Fixing The Technical Debt • 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.
Case Study #3 • Anti-Pattern: Code that plays together stays together
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”.
Example of Class Pollution Credit: Phil Winstanley (http://weblogs.asp.net/Plip/)
Why Is This Technical Debt? • Borrow time now, repay later • Borrowed time now • Simpler object graph • Repay later in cost of adding functionality.
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.
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.
Fixing The Technical Debt • 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.
Case Study #4 • The Anti-Pattern: Sensitive Tests
Symptoms • Test which are sensitive to • Context • Interface • Data • Pass in one iteration • Fail in the next due to changes.
Why Is This Technical Debt? • Borrow time now, repay later • Borrowed time in the form of easy to write tests • Repay later in form of fixing sensitive tests.
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.
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 • Apply those figures to our formula and: • Technical debt = 392 Euros.
Fixing The Technical Debt • 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.