Technical debt and refactoring: the loan and its repayment

The ninth unit turns from the practices to their residue, and asks what a product owes after years of such changes. Cunningham (1992) wrote that shipping first-time code is like going into debt. A little debt speeds development, so long as the team repays it promptly with a rewrite. Every minute spent working around not-quite-right code is interest on the loan. What is borrowed is time, not code, and the debt exists only while somebody pays for it. The judgement this unit defends is therefore not whether a shortcut is permissible. It is whether the repayment is scheduled, owned and visible. A single maintainer may have no slack for repayment. The literature is more confident about the metaphor than about the schedule.

The metaphor was a demand for repayment, and the portfolio reading makes it manageable

Cunningham's WyCash report makes a narrow claim. An unconsolidated implementation, left alone, can bring an organisation to a standstill.

The system was WyCash, a portfolio management application for the cash markets. The team wrote it in Smalltalk and grew it from a working prototype (Cunningham, 1992). The debt the metaphor names was the gap between the code and what the team had since learned about the financial objects. That is why the report's remedy is a rewrite of the mature parts rather than a schedule of small repairs.

Fowler (2009) sharpened the vocabulary without measuring anything. His note separates deliberate from inadvertent debt, and prudent from reckless debt. It argues that the useful distinction is not between debt and non-debt but between prudent and reckless debt. A prudent debt taken to reach a release may not be worth paying down if its interest is small, as in a rarely touched part of the code base. He adds one cell that resists any schedule, prudent but inadvertent, in which a team delivers good work and only later sees what the design should have been. That debt nobody chose is what a repayment plan is likely to miss.

Kruchten, Nord and Ozkaya (2012) moved the metaphor towards theory by organising the technical debt landscape. They argued that the term, having come to describe many phenomena, needed a structure. Their framing is economic: debt is a portfolio of principal, interest and repayment decisions, to be managed rather than regretted. A portfolio can be compared, prioritised and budgeted, which is where "scheduled" comes from.

The metaphor is under-specified, which makes it hard to argue about

Tom, Aurum and Vidgen (2013) put that framing under pressure. A multivocal literature review and interviews produced a taxonomy with strategic, tactical, incremental and inadvertent categories. Their conclusion is that thinking about the concept remained abstract and anecdotal. If the term covers a hard-coded rule, a tangled module and an obsolete library, the word debt does not say which is worth repaying first.

Ernst, Bellomo, Ozkaya, Nord and Gorton (2015) give the sharpest evidence on what practitioners do with it. They surveyed 1,831 engineers and architects at three large organisations, and they interviewed seven. Architectural decisions emerged as the most important single source of debt. The interest has since been measured in one company: Besker, Martini and Bosch (2019) had 43 developers report twice a week for seven weeks on time lost to debt.

Albuquerque and others (2022) surveyed 120 practitioners from 86 organisations in five countries. Recognition of debt was wide, with more than 70 per cent of respondents familiar with the concept, and 72 per cent able to give a valid example in their own artefacts. Formal measurement and documented repayment plans were rare.

Refactoring is the repayment mechanic, and it is cheaper to name than to justify

Fowler (2018) supplies the mechanics of repayment. The book offers a catalogue of named refactorings, each a small step that changes structure without changing behaviour. It also offers a vocabulary of code smells that marks where one is worth making. Naming the step turns an argument about taste into a decision a team can review and reverse, which makes repayment schedulable. Its evidence, though, is experience rather than measurement.

Moser, Sillitti, Abrahamsson and Succi (2006) supply one of the few measurements, and it is small. In a close-to-industrial agile case study they analysed the effect of refactoring on internal quality metrics. Their findings sustain the hypothesis that it enhances the quality and reusability of otherwise hard-to-reuse classes. The authors ask for further experimentation.

The largest field study finds the benefit uneven and the word itself unstable

Kim, Zimmermann and Nagappan (2014) give the largest field study, and it cuts both ways. Using a survey, interviews and the Windows version history, they found that the word refactoring is not confined in practice to strict semantics-preserving transformations. Developers also perceive substantial cost and risk. In the Windows 7 history the top 5 per cent of preferentially refactored modules reduced inter-module dependencies by a factor of 0.85. The rest increased theirs by 1.10. Their conclusion, that impact needs several dimensions, warns against one metric as proof.

Silva, Tsantalis and Valente (2016) ask why developers refactor at all. They compiled 44 distinct motivations for 12 well-known refactoring types, and they found that refactoring is driven mainly by changes in requirements and much less by code smells.

Architectural debt is where the interest compounds

Li, Liang and Avgeriou (2015) give architectural debt a method rather than a feeling. Their approach identifies it from the gap between architectural decisions and the change scenarios that later arrive. A case study at a large telecommunications company found the approach useful and easy to use. It applies before the code exists, where code-based analysis cannot.

Besker, Martini and Bosch (2018) reviewed the architectural debt literature and produced a unified descriptive model of its categories and effects. They also report that studies of how organisations manage such debt are lacking. The scale is accepted. The management evidence is not there yet.

New debt classes arrive faster than an agreed way to rank them

Sculley and others (2015) extend the vocabulary to machine learning systems, the newest pressure on the thesis. They find massive ongoing maintenance costs common in real-world ML systems. They name risk factors including boundary erosion, entanglement and data dependencies. None of those appears to a code smell detector, because the debt sits between model, data and world.

Lenarduzzi and others (2021) reviewed the prioritisation literature. Their systematic review covered 557 unique papers published up to 2020 and included 44 primary studies. Many approaches exist, each optimising different criteria, and their measures capture only part of the factors.

Contested question: is debt a portfolio that can be managed, or a name for whatever a team regrets?

The disagreement is not about whether debt exists. It is about whether it can be quantified. Kruchten and others (2012) hold the portfolio position. Principal, interest and repayment are quantities, so debts can be compared, prioritised and budgeted. Fowler (2009) sits inside that camp but is stricter about admission. He reserves the word for cases where a considered decision bought something, while conceding that even a well-run portfolio contains debts nobody chose.

Tom and others (2013) and Ernst and others (2015) hold that the metaphor does less work than the portfolio language claims. Debt is recognisable but rarely measured, and no practice carries it beyond communication. On this reading the problem is not neglect but incommensurability. A hard-coded rule and a tangled module may share no unit of account, so nobody can compute the interest.

One study would settle it. It would treat a debt item as a first-class artefact. A team would record each deliberate shortcut with a date, an owner and a candidate repayment, and measure its interest as change effort or defects in the affected files. Somebody follows the item until the team repays it or abandons it. Lenarduzzi and others (2021) report that the field lacks rigorous evaluations, so nobody has run that test. Kim and others (2014) show why it is hard even at the scale of Windows, where the largest refactoring effort on record was readable only across several metrics.

What to do while the dispute is open

The evidence is thin on both sides. The portfolio position is a framing paper with no measurement (Kruchten and others, 2012). The sceptical position rests on a multivocal review and two surveys, each reporting recognition without measurement (Tom and others, 2013; Ernst and others, 2015; Albuquerque and others, 2022). The strongest objection to this unit's thesis is that a repayment schedule can become a debt of its own, because recording and prioritising every shortcut spends the same attention twice. While the dispute is open, a designer should record each deliberate shortcut with an owner and a date, and price its interest in the change effort it adds rather than in a score.

Where the argument is heading

The live direction is instrumentation: making debt visible inside the tools teams already use. Lenarduzzi and others (2021) map the prioritisation approaches that exist and the evaluations that are missing. Albuquerque and others (2022) show that recognition without documentation is the norm. Sculley and others (2015) show why the next class of systems makes the problem harder, since a learned component's most expensive debt sits in boundaries no linter sees.

The sources this unit rests on

• Cunningham, W. (1992). The WyCash Portfolio Management System. In Addendum to the Proceedings of OOPSLA 1992. New York: ACM, 29-30. doi:10.1145/157709.157715 A short experience report that introduces the debt metaphor as an argument for prompt repayment with a rewrite. It is the primary source for reading the metaphor as a demand, not a licence.
• Fowler, M. (2009). TechnicalDebtQuadrant. Available at: https://martinfowler.com/bliki/TechnicalDebtQuadrant.html A short note separating deliberate from inadvertent and prudent from reckless debt, and arguing the useful distinction is prudent against reckless. Its inadvertent cell names debt nobody chose, so a schedule has to be sought.
• Kruchten, P., Nord, R. L. and Ozkaya, I. (2012). Technical Debt: From Metaphor to Theory and Practice. IEEE Software 29(6), 18-21. doi:10.1109/MS.2012.167 The authors organise the technical debt landscape and frame debt as a portfolio of principal, interest and repayment decisions. It is the source of the claim that debt is run rather than regretted.
• Tom, E., Aurum, A. and Vidgen, R. (2013). An exploration of technical debt. Journal of Systems and Software 86(6), 1498-1516. doi:10.1016/j.jss.2012.12.052 A multivocal literature review and interviews produced a taxonomy of strategic, tactical, incremental and inadvertent debt, and judged thinking about the concept abstract and anecdotal.
• Ernst, N. A., Bellomo, S., Ozkaya, I., Nord, R. L. and Gorton, I. (2015). Measure It? Manage It? Ignore It? Software Practitioners and Technical Debt. In FSE 2015. New York: ACM, 50-60. doi:10.1145/2786805.2786848 A survey of 1,831 engineers and architects at three large organisations, with interviews of seven. Architectural decisions emerge as the most important source of debt.
• Fowler, M. (2018). Refactoring: Improving the Design of Existing Code. 2nd edition. Boston, MA: Addison-Wesley. https://www.informit.com/store/refactoring-improving-the-design-of-existing-code-9780134757599 The book catalogues named refactorings as small steps that change structure without changing behaviour, and supplies a vocabulary of code smells. Its evidence is experience rather than measurement.
• Moser, R., Sillitti, A., Abrahamsson, P. and Succi, G. (2006). Does Refactoring Improve Reusability? In ICSR 2006. Lecture Notes in Computer Science 4039. Berlin: Springer, 287-297. doi:10.1007/11763864_21 A close-to-industrial agile case study analysing refactoring's effect on internal quality metrics. It sustains the hypothesis that refactoring improves quality and reusability, and its authors ask for further experimentation.
• Kim, M., Zimmermann, T. and Nagappan, N. (2014). An Empirical Study of Refactoring Challenges and Benefits at Microsoft. IEEE Transactions on Software Engineering 40(7), 633-649. doi:10.1109/TSE.2014.2318734 A field study combining a survey, interviews and analysis of Windows version history. The top 5 per cent of preferentially refactored modules reduced inter-module dependencies by a factor of 0.85 against 1.10 for the rest.
• Silva, D., Tsantalis, N. and Valente, M. T. (2016). Why We Refactor? Confessions of GitHub Contributors. In FSE 2016. New York: ACM, 858-870. doi:10.1145/2950290.2950305 Monitoring Java projects on GitHub and asking contributors to explain their refactorings, the authors compiled 44 motivations for 12 refactoring types. Refactoring is driven mainly by changes in requirements, not code smells.
• Li, Z., Liang, P. and Avgeriou, P. (2015). Architectural Technical Debt Identification Based on Architecture Decisions and Change Scenarios. In WICSA 2015. Piscataway, NJ: IEEE, 65-74. doi:10.1109/WICSA.2015.19 The authors identify architectural debt from the gap between architecture decisions and later change scenarios, validating the approach at a large telecommunications company. It works before the code exists.
• Besker, T., Martini, A. and Bosch, J. (2018). Managing architectural technical debt: A unified model and systematic literature review. Journal of Systems and Software 135, 1-16. doi:10.1016/j.jss.2017.09.025 A systematic review producing a unified model of architectural debt categories and effects, while finding studies of how organisations manage it to be lacking. The scale is accepted; its management is unproven.
• Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D. et al. (2015). Hidden Technical Debt in Machine Learning Systems. In Advances in Neural Information Processing Systems 28. Red Hook, NY: Curran Associates, 2503-2511. https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html Applying technical debt to real machine learning systems, the authors find massive ongoing maintenance costs common and name boundary erosion, entanglement and undeclared consumers.
• Lenarduzzi, V., Besker, T., Taibi, D., Martini, A. and Arcelli Fontana, F. (2021). A systematic literature review on Technical Debt prioritization: Strategies, processes, factors, and tools. Journal of Systems and Software 171, Article 110827. doi:10.1016/j.jss.2020.110827 A systematic review of 557 unique papers up to 2020 that included 44 primary studies of debt prioritisation; the approaches capture only part of the factors used in practice.
• Albuquerque, D., Guimaraes, E., Tonin, G., Perkusich, M., Almeida, H. and Perkusich, A. (2022). Perceptions of Technical Debt and its Management Activities: A Survey of Brazilian Software Practitioners. In SBQS 2022. New York: ACM, 230-239. doi:10.1145/3555228.3555237 An online survey of 120 practitioners from 86 organisations in five countries: debt is widely recognised, with 72 per cent able to give a valid example, yet repayment plans are rare.
• Besker, T., Martini, A. and Bosch, J. (2019). Software Developer Productivity Loss Due to Technical Debt. Journal of Systems and Software 156, 41-61. doi:10.1016/j.jss.2019.06.004 A diary study of 43 developers that measured the interest: 23 per cent of their working time lost to debt on average.