I've increasingly come to believe the only difference between experienced and inexperienced software developers is that the experienced ones realize when they're making mistakes. The same rule applies to software projects and project managers. If you're not actively scanning through the list of Classic Software Development Mistakes as you run your software project, you have no idea how likely it is you're making one of these mistakes right now.
In the current downturn lots of companies carried low amounts of well managed financial debt and still went bankrupt when their, previously stable, line of credit was withdrawn by the banks.
Unforeseen things happenTeam members get:SickMove to other rolesBetter job offersYour market can:CollapseGain a new competitorExpand faster than you thought
Cost per feature over time
Cost per feature over time
Bad news: Quantifying Technical Debt is hardGood news: Doesn’t matter how you do itProvided:It’s meaningful to your enterpriseYou are consistent.
You can’t see technical debtSo how do spot something you can’t see?Astronomers have the same problemPlanets that could support life can’t be seen:Life supporting planets must be close to starsThe light from the star hides the planetSo how to they spot the planets?They look for the effect the hidden planet hasWe can do the same with technical debt.
Credit Crunch CodeTechnical Debt By Woody Pewitt firstname.lastname@example.org @woodyp
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.
Big ball of mud! A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-baling-wire, spaghetti-code jungle. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems. People who maintain such systems, are often seen wearing socks and sandals.
How to you get them? The Big Ball of Mud and Other Architectural Disasters http://www.codinghorror.com Jeff Atwood On Brian Foote & Joseph Yoder's Big Ball of Mud paper
How to you get them? Shantytown, Spaghetti Code Throwaway Code Piecemeal Growth Keep It Working Shearing Layers Sweeping It Under The Rug Reconstruction
Steve McConnell's36 classic mistakes People Mistakes Undermined motivation Weak personnel Uncontrolled problem employees Heroics Adding people to a late project Noisy, crowded offices Friction between developers and customers Unrealistic expectations Lack of effective project sponsorship Lack of stakeholder buy-in Lack of user input Politics placed over substance Wishful thinking
Steve McConnell's36 classic mistakes Process Mistakes Overly optimistic schedules Insufficient risk management Contractor failure Insufficient planning Abandonment of planning under pressure Wasted time during the fuzzy front end Shortchanged upstream activities Inadequate design Shortchanged quality assurance Insufficient management controls Premature or too frequent convergence Omitting necessary tasks from estimates Planning to catch up later Code-like-hell programming
Steve McConnell's36 classic mistakes Product Mistakes Requirements gold-plating Feature creep Developer gold-plating Push me, pull me negotiation Research-oriented development
Steve McConnell's36 classic mistakes Technology Mistakes Silver-bullet syndrome Overestimated savings from new tools or methods Switching tools in the middle of a project Lack of automated source control
Technical Debt Quadrant Deliberate "We must ship now and deal with consequences" "We don't have time for design" Prudent Reckless "Now we know how we should have done it" "What's Layering" Inadvertent
Classes of Technical Debt Planned 1 3 Known Unknown 2 4 Unplanned
Basic FormulaTo 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 = $45 / hour Architect = $46 / hour Lead Developer = $41 / hour Developer = $36 / hour Tester = $27 / hour Tech. Support = $20 / hour Business Analyst = $44 / hour. *Hourly rate = average annual salary / (52 – 4wks AL * 5 – 9 days PH * 8 hrs) ***Correct as of November ’10. 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 TechnicalDebt: 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 = $82
Quantify the TechnicalDebt: WF 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 = $285 Value of the technical debt = $203
Potential Cost Per Project So the TD / defect = $202 The av. number of defects / project = 283* Potential TD / project = $57,166 *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 TechnicalDebt? 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 : $34,050
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 TechnicalDebt? 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 theTechnical 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: $61,290.
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 ThisTechnical 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 theTechnical 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 = $536.35.
Fixing TheTechnical 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.
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.
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!
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
Questions? There wasn’t time for my question Where can I contact you? email@example.com www.woodyp.info @woodyp
Thank You! By Woody Pewitt firstname.lastname@example.org www.devexpress.com/woody @woodyp