ERA - Tracking Technical Debt


Published on

Paper: Tracking Technical Debt - An Exploratory Case Study

Authors: Yuepu Guo, Carolyn Seaman, Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, Clauirton Siebra

Session: Early Research Achievement Track Session 3

Published in: Economy & Finance, Business
  • 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

ERA - Tracking Technical Debt

  1. 1. ICSM 2011Williamsburg,VA, USAMay 25 – May 30, 2011 Tracking Technical Debt — An Exploratory Case Study Yuepu Guo, Carolyn Seaman Information Systems Department, University of Maryland Baltimore County, USA Rebeka Gomes, Antonio Cavalcanti, Graziela Tonin, Fabio Q. B. Da Silva, André L. M. Santos, Clauirton Siebra CIn/UFPE - Center of Informatics at Federal University of Pernambuco, Brazil
  2. 2. Introduction Technical Debt  Delaying software maintenance tasks for short term gain but possible long term cost  Risk – additional cost (interest) and uncertainty of interest payment  Decision – what technical debt should be paid off and when? Management Practice  IMPLICIT technical debt management  Experience-based decision making (no rigorous measurement) Proposed Research  Cost-benefit relationships of incurring technical debt  Costs and benefits of EXPLICIT technical debt management  Retrospective study Research Questions  How and to what extent technical debt affects software projects?  Is the decision simulation is effective to uncover the benefits of explicit technical debt management?2
  3. 3. Background Larger Research Project  Measuring and Monitoring Technical Debt Technical Debt Management Framework ID 20 Date TD 7/18/2009 Measurement Responsible Rose Angel Type TD Documentation TD Location Identification Module S Monitoring Description In the last release, function F was added to TD module S, but the documentation has not been updated to reflect this change. Principal List 3.5 person-day Interest Amount: 1.5 person-day Interest Probability 40%3
  4. 4. Subject Technical Debt Item System  Software application from a multi-national company  Client solution for Microsoft Exchange Server  63,218 LOC and over 5 years of evolution with 20 developers involved D1 D3 Evolution D2 R1 R2 Cost X 2011  D1: Decision to maintain WebDAV communication protocol D1: Decision to maintain WebDAV protocol  D2: Decision to couple persistenceand communication layers D2: Decision to coupple persistence and communication layers D3: Decision to support MS Exchange 2007  D3: Decision to upgrade to ActiveSync communication protocol R1: First system release R2: First maintenance release  R1: First system release  R2: Second system release Technical Debt Item  Delayed change of the communication protocol (T1)4
  5. 5. Methodology Measurement  Technical debt item (T1)  Principal: Effort to switch to ActiveSync (new protocol)  Interest Amount: Rework effort on affected modules  Interest Probability  Coupling the communication and persistence layers  Switching to ActiveSync  Impact of T1  Gain: Principal  Loss: Interest Amount × Interest Probability Decision Simulation Process Estimate Track TD item Simulate Compare principal and at D1 decision decisions interest5
  6. 6. Results Decisions D1 D2 D3 Actual Defer Defer Defer Decision Simulated Pay Pay Pay Decision Simulated Cost/Benefit Analysis The value of explicit technical debt management 1000 929 800 Labor-hour 585 600 507 507 507 400 Beneift Cost 200 65 0 D1 D2 D36 Decision Point
  7. 7. Conclusion Technical debt may have significant impact on software projects (tripled the development cost in this case) A decision made without careful analysis could aggravate the negative effect of technical debt Explicit management of technical debt could prevent high cost incurred by technical debt Decision simulation provides an effective approach to the technical debt problem Business factors  Real benefit of incurring the technical debt  Over-simplicity of the approach  Multi-disciplinary team7
  8. 8. Questions?8