Advertisement

Empirical Software Engineering

, Volume 21, Issue 1, pp 159–182 | Cite as

Exploring the costs of technical debt management – a case study

  • Yuepu Guo
  • Rodrigo Oliveira Spínola
  • Carolyn Seaman
Article

Abstract

Technical debt is a metaphor for delayed software maintenance tasks. Incurring technical debt may bring short-term benefits to a project, but such benefits are often achieved at the cost of extra work in future, analogous to paying interest on the debt. Currently technical debt is managed implicitly, if at all. However, on large systems, it is too easy to lose track of delayed tasks or to misunderstand their impact. Therefore, we have proposed a new approach to managing technical debt, which we believe to be helpful for software managers to make informed decisions. In this study we explored the costs of the new approach by tracking the technical debt management activities in an on-going software project. The results from the study provided insights into the impact of technical debt management on software projects. In particular, we found that there is a significant start-up cost when beginning to track and monitor technical debt, but the cost of ongoing management soon declines to very reasonable levels.

Keywords

Technical debt Decision making Cost Case study 

References

  1. Alberts CJ et al (1996) Continuous risk management guidebook. Software Engineering Institute Carnegie Mellon University, PittsburghGoogle Scholar
  2. Alter S, Ginzberg M (1978) Managing uncertainty in MIS implementation. Sloan Manag Rev 20:23–31Google Scholar
  3. Bachmann F, Nord R L, Ozkaya I (2012) Architectural tactics to support rapid and agile stability. CrossTalk, May/June-2012:20–25Google Scholar
  4. Boehm BW (1991) Software risk management: principles and practices. IEEE Softw 8:32CrossRefGoogle Scholar
  5. Boehm BW (1981), Software engineering economics. Englewood Cliffs, Prentice-Hall, New Jersey, USAGoogle Scholar
  6. Bohnet J, Döllner J (2011) Monitoring code quality and development activity by software maps. In: Proceedings of the 2nd workshop on managing technical debt (MTD ’11), pp 9–16Google Scholar
  7. Brondum J, Zhu L (2012) Visualizing Architectural Dependencies. In: Proceedings of the 3rd workshop on managing technical debt (MTD ’12), pp 7–14Google Scholar
  8. Brown N, Nord R L, Ozkaya I, Pais M (2011) Analysis and management of architectural dependencies in iterative release planning. In: Proceedings of the 9th working IEEE/IFIP conference on software architecture (WICSA), pp.103-112Google Scholar
  9. CAST (2012) Cast worldwide application software quality study: summary of key findings. Cast reportGoogle Scholar
  10. Charette RN (1989) Software engineering, risk analysis and management Intertext publications. McGraw-Hill Book Co, New YorkGoogle Scholar
  11. Cunningham W (1992) The wycash portfolio management system. In: Addendum to the proceedings on Object-oriented programming systems, languages, and applications, pp 29–30Google Scholar
  12. Dalkey N, Helmer O (1963) An experimental application of the delphi method to the use of experts. Manag Sci 9:458–467CrossRefGoogle Scholar
  13. DoD U (2006) Risk management guide for DoD acquisition. Department of Defense, USAGoogle Scholar
  14. Emden E V, Moonen L (2002) Java quality assurance by detecting code smells. In: Proceedings of the ninth working conference on reverse engineering, pp 97–106Google Scholar
  15. Fairley R (1994) Risk management for software projects. IEEE Softw 11:57–67CrossRefGoogle Scholar
  16. Fowler M (2003) Technical debt. Web. http://www.martinfowler.com/bliki/TechnicalDebt.html. Accessed 1 May 2008
  17. Fowler M (2007) Design stamina hypothesis. Web. http://www.martinfowler.com/bliki/DesignStaminaHypothesis.html. Accessed 1 May 2008
  18. Fowler M (2009) Technical debt quadrant. Web. http://martinfowler.com/bliki/TechnicalDebtQuadrant.html. Accessed 1 Dec 2013
  19. Fowler M, Beck K, Brant J, Opdyke W, Roberts D (1999) Refactoring: improving the design of existing code, Addison-WesleyGoogle Scholar
  20. Gaudin O (2009) Evaluate your technical debt with Sonar. http://www.sonarqube.org/evaluate-your-technical-debt-with-sonar. Accessed 1 June 2014
  21. Guo Y, Seaman C, Gomes R, Cavalcanti A, Tonin G, Da Silva F Q B, Santos A L M, Siebra C (2011) Tracking technical debt – an exploratory case study. In: Proceedings of 27th IEEE international conference on software Maintenance (ICSM’11), pp 528–531Google Scholar
  22. Higuera RP, Haimes YY (1996) Software risk management. Software Engineering Institute Carnegie Mellon University, PittsburghGoogle Scholar
  23. ISO (2002) Risk management - principles and guidelines on implementation. International Organization for StandardizationGoogle Scholar
  24. Kontio J (2001) Software engineering risk management: a method, improvement framework and empirical evaluation. Dissertation, Helsinki University of TechnologyGoogle Scholar
  25. Lester A (2008) Get out of technical debt. Web. http://petdance.com/perl/technical-debt/. Accessed 1 May 2008
  26. Letouzey, J-L (2012) The SQALE method for evaluating technical debt. In: Proceedings of the 3rd workshop on managing technical debt (MTD’12), pp 31–36Google Scholar
  27. Leung H, Fan Z (2002) Software cost estimation. Handbook of software engineering and knowledge engineering. World Scientific Pub Co, River EdgeGoogle Scholar
  28. Marinescu R (2012) Assessing technical debt by identifying design flaws in software systems. IBM J Res Dev 56(5):1–13CrossRefGoogle Scholar
  29. McConnell S (2007) 10x software development. Web. http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx. Accessed 1 May 2008
  30. Mo R, Garcia, J, Cai Y, Medvidovic N (2013) Mapping Architectural Decay Instances into Dependency Models. In: Proceedings of the 4th workshop on managing technical debt (MTD ’13), pp 39–46Google Scholar
  31. Nord R L, Ozkaya I, Kruchten P, Gonzalez-Rojas M (2012) In search of a metric for managing architectural technical debt. In: Proceedings of the joint 10th working IEEE/IFIP conference on software architecture (WICSA) and the 6th European conference on software architecture (ECSA), pp 91–100Google Scholar
  32. Nugroho A, Visser J, Kuipers T (2011) An empirical model of technical debt and interest. In: Proceedings of the 2nd workshop on managing technical debt (MTD ’11), pp 1–8Google Scholar
  33. Parkinson CN (1957) Parkinson’s law and other studies in administration. Houghton Mifflin, BostonGoogle Scholar
  34. Putnam LH (1978) A general empirical solution to the macro software sizing and estimating problem. IEEE Trans Softw Eng 4:345–361CrossRefzbMATHGoogle Scholar
  35. Rothman J (2006) An incremental technique to pay off testing technical debt. Web. http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=11011&tth=DYN&tt=siteemail&iDyn=2. Accessed 1 May 2008
  36. Schmid K (2013) A formal approach to technical debt decision making. In: Proceedings of the 9th international ACM Sigsoft conference on quality of software architectures (QoSA’13), pp 153–162Google Scholar
  37. Seaman C, Guo Y (2011) Measuring and monitoring technical debt. Adv Comput 82:25–46CrossRefGoogle Scholar
  38. Shepperd M, Kadoda G (2001) Comparing software prediction techniques using simulation. IEEE Trans Softw Eng 27:1014–1022CrossRefGoogle Scholar
  39. Sisti FJ, Joseph S (1994) Software risk evaluation method. Software Engineering Institute Carnegie Mellon University, PittsburghGoogle Scholar
  40. Stamatelatos M (2002) Probabilistic risk assessment procedures guide for nasa managers and practitioners. NASAGoogle Scholar
  41. Wang P, Yang J, Tan L, Kroeger R, Morgenthaler J D (2013) Generating precise pependencies for large software. In: Proceedings of the 4th workshop on managing technical debt (MTD ’13), pp 47–50Google Scholar
  42. Yin RK (1994) Case study research: design and methods, 2nd edn. Sage Publications, Thousand OaksGoogle Scholar
  43. Zazworka N, Seaman C, Shull F (2011) Prioritizing design debt investment opportunities. In: Proceedings of the 2nd workshop on managing technical debt (MTD ’11), pp 39–42Google Scholar

Copyright information

© Springer Science+Business Media New York 2014

Authors and Affiliations

  • Yuepu Guo
    • 1
  • Rodrigo Oliveira Spínola
    • 2
    • 3
  • Carolyn Seaman
    • 1
  1. 1.Department of Information SystemsUniversity of Maryland Baltimore CountyBaltimoreUSA
  2. 2.Department of Systems and ComputingUniversity of SalvadorSalvadorBrazil
  3. 3.Fraunhofer Project Center for Software and System Engineering at Federal University of BahiaSalvadorBrazil

Personalised recommendations