Quality Debt: Is Your Project Going Bankrupt?


Published on

Every decision made during the course of a project can affect the quality of the final product. Compromises in functionality, design, or implementation invariably come with a cost, which must be paid. Without an adequate measure of the debt a product is carrying, no strategy to repay it can be formulated, and the project may ultimately become bankrupt, affecting your business case, your users’ productivity, and your organization’s bottom line. Taking from the concept of technical debt, Jordan Setters gives it a quality twist. “Quality debt” is the cost in time and money paid by the system's users through productivity lost due to inefficient functionality. Learn how to measure, track, and prioritize this debt. Discover ways to manage your quality debt and how to organize development to pay back the interest and principal as soon as possible. Take back an approach for using quality debt as a tool to inform project stakeholders of both the costs and the added business value of their decisions and choices.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Quality Debt: Is Your Project Going Bankrupt?

  1. 1.     BT7 Session  6/6/2013 2:15 PM                "Quality Debt: Is Your Project Going Bankrupt?"       Presented by: Jordan Setters PlanIT Software Testing LTD, New Zealand                   Brought to you by:        340 Corporate Way, Suite 300, Orange Park, FL 32073  888‐268‐8770 ∙ 904‐278‐0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com
  2. 2. Jordan Setters Planit Software Testing, Ltd. A test consultant for Planit Software Testing, Ltd. in New Zealand, Jordan Setters has been in software testing for twelve years in both the public and commercial sectors. Jordan has worked with companies as diverse as Telecom NZ, testing their capacity to lawfully intercept communications for law enforcement agencies; Transpower NZ, helping implement a new electricity market system to manage New Zealand’s national power grid; and the Ministry of Social Development. Jordan is proud of his hands on approach to testing. A proponent of pragmatic testing approaches, Jordan is passionate about achieving the best possible system for the users, using whatever means and methods necessary.  
  3. 3. Quality Debt Is your project going bankrupt? Presented by: Jordan Setters jsetters@planittesting.co.nz So . . . What is “Quality Debt”
  4. 4. A Brief on “Technical Debt” Ward Cunningham: inventor of Wiki, and all around brainy guy Shipping first time code is like going into debt. A little debt speeds debt development so long as it is paid back promptly with a rewrite. . . . The danger occurs when the debt is not repaid. Every minute spent on notquite-right code counts as interest on that debt. Entire engineering organisation can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise. -Ward Cunningham, 1992- A Brief on “Technical Debt” Debt can be simply broken into two parts: Principal: The direct cost of fixing those structural flaws in the production system – at a minimum is a cost calculated by: • number of hours to fix x • fully burdened hourly cost of those involved – design, developing, testing
  5. 5. A Brief on “Technical Debt” Interest: Continuing costs: Contin ing costs The amount of time amo nt (therefore money) developers spend in working around known design flaws, limitations, and bugs while coding new features – i.e. inefficiency See also: Business Risk, Liability, Risk, & Opportunity Cost © Planit Test Management Solutions Pty Ltd 2008 A “Quality Debt” Concept “Technical Debt” often doesn’t present itself into defects during the testing or use of the system - It is a debt to the developers We (testers) deal with decisions that affect the quality of the system to the user - This is debt to the user / business . . . ”Quality Debt”
  6. 6. A “Quality Debt” Concept Jordan Setters: Stylish Bass god, and the best tester in the world (according to him anyway) The first time code is released to production is like going into debt. A little debt speeds the project along, so long as it is paid back promptly with a rewrite. . . . The danger occurs when the debt is not repaid. Every minute the users spend on not-quite-right functionality counts as interest on that debt. Entire development projects can be brought to a stand still stand-still under the debt load of bad functionality, defects or otherwise. -Jordan Setters, 2012: shamelessly paraphrasing Ward Cunningham - What it looks like when we get it wrong © Planit Test Management Solutions Pty Ltd 2008
  7. 7. Types of Quality Debt Unintentional: These are not strategic, b t are a result of Th t t t i but lt f people doing a bad job and is often occurred unknowingly: • • • Bad Coding* A poor design approach Incomplete requirements* requirements Types of Quality Debt Intentional: Project makes a conscious decision to optimise for the present at the expense of the future. Characterised by decisions that include statements like: • “If we don’t get this release done on time, there won t won’t be a next one one” • “We don’t have the time to . . .” • “We can work around by . . .” • “We’ll clean this up later” • “We’ll do that after go live . . . in another phase”
  8. 8. Be sure you are taking on the right kind of Debt Some debt is taken on in large chunks: “We don’t have time to do it right, so we’ll fix it after go-live” – akin to large debt like buying a car, it can be tracked and measured. Be sure you are taking on the right kind of Debt Other debt accumulates from taking hundreds of short cuts – akin to Credit short-cuts Card debt • • • Easy to incur unintentionally It adds up faster than you think It’s much harder to manage and track © Planit Test Management Solutions Pty Ltd 2008
  9. 9. Debt MUST BE SERVICED There is a tipping point • D th by a thousand WTF’s Death b th d WTF’ • The debt of the hundred little inefficiencies building up, adding time and frustration to their daily tasks • This is “Interest” on your debt. Often not paid by th project, b t paid by Oft t id b the j t but id b the business in lost time and productivity. Debt MUST BE SERVICED When do you know you have Problem • • • • • • • A growing dislike for the system admitted by developers, testers, and users Small defects never get fixed A bad user experience or UI is a clue it is rotten to the core Growing number of workarounds Consistently not meeting requirements Lack of knowledge of what the system does and why Unused features
  10. 10. Debt MUST BE SERVICED When are you in over your head • • • • • • • Deep contempt for the system All knowledgeable developers, testers, and SME have disavowed the system or left Infrequent software releases Bug fixes take too long Lots of “Sorry”, “OMG”, “WTF”, and Sorry OMG WTF “$%#&*!!” comments Documentation is no longer useful as a test oracle Work arounds are now enshrined in the user experience GMAS Example © Planit Test Management Solutions Pty Ltd 2008
  11. 11. Managing Debt in an Agile World The way debt can be measured and dealt with in Agile Hardening Iteration Debt a part of product backlog More opportunity to payback debt before it becomes an issue More likelihood of accumulating ‘credit card’ debt © Planit Test Management Solutions Pty Ltd 2008 The “No Defect” Mindset “What he needs is some way to pay back. Not some way to borrow more ” more. - Will Rogers At any given time, the highest priority is to eliminate bugs before writing any new code. © Planit Test Management Solutions Pty Ltd 2008
  12. 12. How Do You Measure Quality Debt Maintain a “Debt List” with defects Keep a track of the “Debt Backlog” p g • when debt is paid off, remove it from the list; • if a debt starts becoming “old” then increase the priority of that fix Must have a useful measure to safeguard against the accumulation of “credit card” debt How Do You Measure Quality Debt You can calculate a cost for Quality Debt (((0.1 ∑ LSV) + (0.25 ∑ MSV) + (0.5 ∑ HSV)) x Time(h) x $ /hour) LSV = Low severity defect MSV = Medium severity defect HSV = High severity defect CAST surveyed 745 applications and the resulting analysis d li l i determined the i d h average Technical Debt = $3.61 per line of code. © Planit Test Management Solutions Pty Ltd 2008
  13. 13. Communicating Quality Debt “For every (dollar) of competitive advantage gained by cutting quality it quality, costs $4 to restore it; and software is an organisational asset and decisions to cut quality must be made by executive management and reflected in the financial statements. statements ” - Ken Schwaber http://www.infog.com/presentations/agile-quality-canary-coalmine © Planit Test Management Solutions Pty Ltd 2008 Communicating Quality Debt This is a concept that y immediately resonates with executives and project management Presents well to both non-technical and technical stake holders alike lik
  14. 14. Communicating Quality Debt • • • Should be contextualised Discuss in terms of money and time rather time, than features or functionality If you can calculate the time of workarounds, then compare with project business case Compare “good debt” with “bad debt” © Planit Test Management Solutions Pty Ltd 2008 Communicating Quality Debt Treat the discussion as an on-going dialogue rather than a single presentation; it may take several discussions before the nuances of the metaphor fully sink in. © Planit Test Management Solutions Pty Ltd 2008
  15. 15. References Curtis, Bill. Paying Down the Interest on Your Applications: A Guide to Measuring and Managing Technical Debt. New York: CAST, 2012 McConnel, Steve. Technical Debt. www.ontechnicaldebt.com, 2007 Schwaber, Ken. www.infog.com/presentations/agile-quality-canarycoalmine Strutz, Nathan. Holistic Program Quality and Technical Debt (presentation). CF. Objective, 2011 Szynkarski, Alexandra. 3 Concepts to Aid Developers in Addressing Techinical Debt. www.ontechnicaldebt.com, 2012 Appendix A: Debt Glossary Technical Debt: These are the activities that a team or team members take shortcuts on now that will impede future development if l t as i d l t let is Quality (Testing) Debt: There is a diminishing ability to verify the functional and technical quality of software: the Break/Fix mentality Configuration Management Debt: Integration and release management become more risky, complex, and error-prone Design Debt: The cost of adding features is increasing toward the point where it is more than the cost of writing from scratch Platform Experience Debt: The availability and alignment of people to business objectives that involve software changes is becoming more limited or cost-prohibitive Non Debt: Feature backlog, deferred features, cut features, etc. Not all incomplete work is debt © Planit Test Management Solutions Pty Ltd 2008