It’s payback time! Developing a strategy to resolve technical debt

Abstract

As companies seek to exploit the full potential of various information systems to reach their strategic goals, they must balance the system-maintenance obligations that arise through the systems’ development and use. As evolution brings new deployments, novel features, and changes in socio-technical configuration while legacy systems get withdrawn, replaced, and reconfigured over time in response to changes in technological/organizational requirements, the challenge of managing technical debt remains etched deeply into the organization’s technology environment. The teaching case addresses organizations’ need to come to grips with the various types of that debt, and to devise a corresponding strategy aligned with their current state. Relevant for executive education in the information systems discipline, the case presents the challenge of managing technical debt and formulating an appropriate strategy for organized efforts to repay it and prevent it from mounting excessively.

Keywords

IS development IS maintenance technical debt teaching case

Setting the scene

As the sun begins to rise over the skyline, you, an experienced professional working at the intersection of business and technology, open your day at the office with the morning’s news while taking your first sip of coffee. To keep in touch with the ever-evolving technology landscape’s latest developments, you begin looking through the headlines. One centered on the “UK postal scandal” soon catches your eye, with “How a software glitch and a centuries-old British company ruined lives” (Cooban, 2024). Diving into the article gives you a summary of the saga of the Horizon IT system, which remained in use for decades after indications emerged in 1999 that the system was plagued with bugs and other defects. The piece chronicles the resulting wrongful prosecution of 900-plus post-office branch managers that followed on the heels of bogus accounting shortfalls reported by the system, alongside numerous other serious consequences, from victims’ imprisonment, financial ruin, and suicide to substantial legal challenges and monetary losses for the organizations involved. “Finally they have some closure,” you think, musing that, though this is quite an extreme example of far-reaching consequences from overlooking software maintenance and development, it does remind you of other cases wherein neglecting fundamental IT-maintenance needs in favor of short-term benefits has led to harmful outcomes.

Indeed, this issue is a vexing one never far from the elbows of information-systems (IS) managers who must judge where to invest limited resources so as to bring the greatest benefit for their organization. Companies no less prominent than Nokia and Royal Bank of Scotland (RBS) count among the casualties of excessive emphasis on reaping immediate gains from legacy systems. Nokia paid the high price of losing leadership of world cell-phone markets by centering its development efforts on outdated Symbian software, and resulting events ultimately spiraled into the entire phone division’s demise (Devico, 2024; Vuori and Huy, 2015), while RBS’s failure to keep a mission-critical banking system congruent with the latest requirements produced disruption to the company’s services, thereby racking up significant financial and reputation damage that sparked headlines such as “RBS fined £56m for IT breakdown” (Treanor, 2014) and “R.B.S. is again hit by a technology failure” (Bray, 2015).

Taking another sip of coffee and reflecting further, you come to the realization that the narratives beyond the striking headlines feature a common denominator: each is underpinned by the broader theme of technical debt. Indeed, technical debt has been recognized as a major roadblock for many organizations’ digital transformation efforts (Burden et al., 2018). Although this concept resonates with many practitioners, its impact on an organization’s responsiveness, its efficiency, and ultimately its bottom line repeatedly gets underestimated. This insidious nature highlights the importance of managing the debt not as an afterthought but as an essential element of strategic IT planning and governance. Through good planning, today’s decisions to take on technical debt—either intentionally or not—need not amass high interest that must be paid later.

For this reason, managing technical debt should be a managerial priority in any organization. Fortunately, you have recently enrolled in a course that deals with this tricky matter methodically, covering the concept of technical debt and its types; explaining the nature of it; and providing a framework with which to identify, assess, and resolve technical debt. You ponder thus: “Since we need to improve the way we address technical debt at this organization, how could I concretize a more coherent way to identify technical debt? And is there a solid approach I could follow to develop an actionable strategy for managing that debt?” To dig for answers to these perplexing thoughts, you turn to the course material for insight.

The concept of technical debt

The metaphor of debt is commonly applied for an obligation to pay off what is owed (see Merriam-Webster, 2024). Possibly the most familiar form of debt is financial debt, which often carries with it an additional obligation to settle interest that compounds over time on the basis of how long it takes to repay the debt, as in the case of a home mortgage. Any entity that seeks to make an investment—that is, to allocate resources in expectations of making a profit or gaining an advantage—can use debt as a lever to amplify returns on a project or other endeavor. Even when the debt appears entirely justified (purchasing expensive heavy machinery can readily improve production capacity and efficiency), accumulate too much debt and in the worst case you might stagger under its weight when payments fall due.

The functioning of technical debt follows parallels to that of financial debt. Building on the latter, this concept refers to future maintenance obligations that accumulate in the process of developing or using information systems and have to be addressed (Ramasubbu and Kemerer, 2016). For example, developers who prioritize activities that drive software-development work in particular frequently take shortcuts in other, related work areas so as to reach immediate development milestones. Among the areas that could suffer accordingly are documentation and software testing. Entities that put insufficient resources into these can incur further technical debt through sub-optimal code and poorly considered software architecture. Thus, taking shortcuts brings on technical debt—future costs of additional work necessitated by choosing a quick, easy, and non-systematic solution in the moment instead of a more sustainable approach that might well require more time. The catch is that the results either way are likely to bring about both beneficial and detrimental outcomes. In the example of poorly documented improvements to software code, personnel may have to perform additional work when needing to revisit the code’s logic and review it to understand reasons for inefficiency, but deferring the documentation effort does permit faster progress in the software-development work. This example spotlights the need for reasonable balance: the organization can address the absence of documentation from the time during or after the initial code-improvement effort before problems with inefficiencies snowball. Ideally, documentation can be added before any acute need for further code revisions arises (before the interest falling due over time spikes). Then, code improvements informed by good documentation can proceed such that code inefficiencies are minimized.

Hence, technical debt accumulates latently in multiple arenas of IS development and use (Alves et al., 2016; Li et al., 2015) and compromises between short- and long-term goals are necessary in all the decision-making, which must strive for a balance that exploits technical debt in the most suitable way. The key, then, is to understand that managing technical debt is a continuous process of finding a meaningful position between the two goals that yields a net positive result for the organization by allowing it to honor both its development goals and maintenance obligations such that the interest does not rise too high. To get to the bottom of the matter, one must clarify the picture by identifying the distinct types of technical debt and their interconnectedness.

Types of technical debt

Early writings on the concept of technical debt referred only to inappropriately written code (Cunningham, 1992), but the concept has since expanded to encompass several types of debt, in response to the phenomenon’s multifaceted nature (Ernst et al., 2021; Rolland et al., 2018). It can manifest itself in various forms, which depend on the context and nature of the project.

The code debt mentioned above emerges from shortcuts during the coding process, that results in sub-optimal/inefficient code that is hard to understand and maintain. This might involve duplication of code, lack of proper error-handling, and overly complex solutions.

Test debt arises from insufficient or inadequate testing for the code base. There might be shortcomings in the thoroughness of unit testing, integration tests, or automated regression checks. Without proper testing, guaranteeing the stability and reliability of the software becomes considerably harder. In particular, the specter of a non-tested software upgrade “breaking” the functioning of a production-use application could encourage inertia.

Design debt accumulates when the architecture or design of a system is not properly thought out or is inappropriately implemented. This can lead to scalability issues, difficulties in adding new features, or a higher likelihood of bugs and errors.

The notion of architecture debt, which displays some parallels with design debt, specifically denotes issues related to the overall architecture of a system. These could be connected with scalability, performance, or maintainability issues arising from architectural decisions made hastily or without suitable attention to long-term implications.

Requirements debt arises through compromises with regard to which requirements to meet, when to address them, and how the responses are to be implemented. It occurs when certain needs are not adequately met in the final system or when fulfilling one requirement hinders meeting of others.

Infrastructure debt, in turn, is connected with disparities between the project’s underlying infrastructure or technology stack and the requirements of the project. Whether taking the form of outdated libraries, unsupported dependencies, or inefficient hardware configurations, at its core are structures that are obsolescent or no longer suitable.

Data debt stems from poor-quality data. Data being incorrectly structured, inaccurate, duplicated, or entirely missing can usher in secondary issues when employees develop workarounds to deal with the shortcomings in the data, potentially increasing complexity and undermining the overall maintainability of the information system. Inability to access data as required might point to systems that are riddled with data debt, whether due to difficulties in accessing necessary data, complete absence of access, or storage in inaccessible locations. Data debt embedded in systems can render processes increasingly difficult to manage, in the absence of the sound data control necessary for their execution.

Next, documentation debt arises from neglecting or improperly seeing to documentation. Other developers ought to be able to consult such material as comments within the code, and users ought to be able to rely on user manuals. Ideally, documentation should comprise valuable, up-to-date information that helps users understand prior decisions and reasoning, reduces the challenges for developers tasked with understanding and maintaining the code, etc. Without clear documentation, information may be lost and the same work might need to be done again and again.

People debt begins to accumulate when sufficient training and hiring practices are not in place and the organization is beset by a lack of knowledge transfer among its personnel. This form of debt tends to be rife when team members leave a project in droves (for instance, upon its completion) or when complex or unfamiliar technologies are involved.

Interconnections between the types of technical debt

As the descriptions of these nine types of technical debt imply, numerous interconnections between forms exist. Addressing one type can lead to a decrease in some while adding to another. Architecture debt has been identified as playing an especially central role in feeding infrastructure, data, people, and documentation debt (Mäki et al., 2023; Martini et al., 2015; Rinta-Kahila et al., 2023; Rolland and Lyytinen, 2021). Figure 1 illustrates potential interconnections among debt types discovered in recent research on one organization that was grabbling with technical debt (Mäki et al., 2023). It shows how architecture debt fuels many debt types through, for instance, sketchy architectural solutions that integrate legacy systems to modern IT platforms using customized connections. This can increase the technical embeddedness of legacy systems (increasing infrastructure debt) and often it is the case that these suboptimal solutions are left undocumented too (increasing documentation debt). Moreover, failing to maintain up-to-date system documentation (documentation debt) about geriatric IT systems (infrastructure debt) makes the organization growingly dependent on few experts who know the workings of the old, undocumented system (i.e., increasing people debt). Note that the figure below shows only some possible interconnections based on the study’s empirical findings—others are likely to exist, depending on the context.

Figure 1.

Possible interconnections among different technical debt types (Mäki et al., 2023).

Hence, a rise in one type of technical debt not only entails interest payments in the form of having to commit additional resources to resolving a related deferred maintenance obligation but also holds potential to plant additional technical debt. Consequently, latently mounting technical debt can lead to ballooning interest, which could establish the aforementioned vicious circles and lead to a situation wherein the organization must dedicate increasing proportions of its resources merely to coping with the growing maintenance obligations.

Having read about what technical debt is and the various ways in which it exhibits itself; you reflect, “All these types ring a bell, and I’ve recently observed some of them in our daily work when we deal with IT systems – be they old or new systems. And some of these sorts of technical debt appear interconnected somehow. Surely, there must be a way to find a balance among them that benefits the organization.” You then consult the next part of the course package in your quest for ideas about how to begin identifying and evaluating the technical debt in your organization.

Strategic management of technical debt

Fuller understanding of the nature of technical debt demands awareness that it can be either planted deliberately or created unintentionally. One can describe intentional debt as a conscious decision to invest resources where attention to the system architecture should yield gains through a choice to favor one software-development or maintenance activity over other activities. Planting debt intentionally can be beneficial if it permits the organization greater flexibility and scalability by relaxing the limits on the options for choosing an appropriate way to pursue its software-maintenance and development work (Rolland et al., 2018). Unintentional debt, in contrast, can result from bad management, lack of understanding, or accidents/mistakes (Mäki et al., 2023) that may even escape notice utterly and thus latently gather technical debt. Here, a dynamic unfolds in which debt accumulates in the background while, in addition, interest begins compounding in the form of unanticipated maintenance obligations. Since the negative consequences worsen over time if left unmanaged and unidentified, it is vital that both the intentionality and the associated risk be evaluated thoroughly (Ernst et al., 2021), by means of the framework presented in Figure 2.

The four quadrants illustrate states in which technical debt may, through varying levels of intentionality and risk management, culminate in risk when an organization is developing and maintaining systems. The intentionality dimension captures whether the organization takes on debt deliberately versus gathering it latently while remaining unaware of it, whereas the risk dimension expresses the approach to managing risk: either reacting to it once the profile of technical debt has grown or engaging actively in keeping its technical debt on a healthy level. Being aware of how the organization as a whole or parts of it can end up in these four states helps to align decision-making with devising of an effective strategy.

The state in the lower-left quadrant, a reckless attitude, reflects the organization being either non-concerned by or blissfully ignorant of how mounting technical debt could bring on a situation of being crushed beneath a heavy load of technical debt (of whatever sort) that draws significant resources from other operations toward dealing with IT-maintenance obligations alone. An organization that has not considered the detrimental effects of mounting technical debt might make fundamentally disadvantageous decisions—for instance, producing ill-considered, flawed system designs that cascade into issues hanging over the IT infrastructure and system architecture, such as further problems affecting data. Thus, the organization might end up caught in a vicious circle—the technical equivalent of paying the interest on a payday loan by taking out another payday loan. If the cycle is not broken, the situation with technical debt is bound to grow dire. A central implication for strategy, then, is that once the current state of technical debt is recognized—either through proactive personnel or once the situation with the systems has grown untenable—the organization must dedicate considerable effort and resources to remedies. This follows from having put off the inevitable without being aware of detrimental consequences in the pipeline.

The diagram’s top-left corner presents a state wherein the process of taking on technical debt is not thoroughly understood, or its potentially negative consequences are insufficiently recognized. With a negligent stance, setting unrealistic timelines for delivering system-development results and being unable to furnish the projects with people who possess pivotal expertise and tacit knowledge can yield sub-optimal and otherwise unsatisfactory outcomes. Development and maintenance efforts adopting such a stance give precedence to short-term efficiency without considering such long-term implications as having to rework portions of the code base or unpick a patchwork of short-term fixes. Still, in some situations it might be reasonable to plant debt without considering the downsides of doing so. When the organization desperately needs a system release that supports reaching strategic goals, the strategy-linked implication for managing technical debt would be to concentrate additional resources on identifying the debt incurred and establishing a more proactive approach to managing the risks of the accumulated debt—as soon as the system release is complete.

In the bottom-right quadrant, in turn, the incidental encounter is a state of happenstance whereby, notwithstanding organized development and maintenance, work on some aspect of a system reveals previously unnoticed technical debt. Such incidental awareness could arise, for instance, during a development initiative that uncovers sub-optimality or outdated components irrespective of earlier adherence to best practice for system design and development. Alternatively, it could be that further training opens system designers’ eyes to approaches that would have been better. There is a crucial implication for strategies here in that they must account for the inevitability of this type of unintentional debt accumulation raising its head from time to time. Therefore, organizations should engage in actively challenging their earlier views of system development so that maintenance obligations can be identified without presenting themselves abruptly. Both learning through practice and participating in relevant training should cultivate not only new skills but also perspectives that improve on current system-development and maintenance practices.

Finally, a vigilant approach represents a well-balanced state wherein the organization takes on technical debt with full intentions of paying it back in an organized manner. Entities lying in this quadrant pay less interest on their technical debt since the decisions to plant it were thoroughly accounted for and there is a realistic plan for settling it. Because the organization has a clear plan to pay it off, the debt can be exploited for the benefit of operations, to yield value sooner than no-debt approaches could have. In addition to possessing a mastery of conscious use of technical debt, the organization is sensitized to knowing when to prevent technical debt from increasing. For instance, the personnel are unlikely to postpone necessary documentation of system changes when there is time to handle it. The implication for solid strategy is that the organization has to foster ongoing commitment to proactively managing the risk of taking on technical debt and being deliberate about why and where to plant it.

Overall, within the framework depicted in Figure 2, organizations should orient their approach such that they always strive for vigilance, since this results in the least resource waste and incurs the smallest amount of interest on the technical debt. Avoiding unnecessary technical debt should be a priority for the organization as a whole and its managers. Crucially, some technical debt is going to be incurred in any case, but a balanced approach to planting, making use of, and resolving it is vital for preventing a slide down the slippery slope to uncontrollable debt.

Finally, another layer of complexity to managing technical debt merits stressing. Namely, technical debt is not purely a result of organization-internal decisions and actions. For instance, the future maintenance obligations connected with the Horizon IT system arose in response to externally imposed pressures too (Cooban, 2024)—such as technological progress that gradually renders systems outdated. Likewise, RBS’s legacy IT system represented the state of the art in banking at one time (Treanor, 2014). Whatever measures are taken to manage technical debt, it is impossible for any organization to completely avoid it. Therefore, it is all the more critical that they be aware of the debt and proactively balance the decisions whereby it waxes and wanes. This inherent compromise highlights the need for ongoing commitment to managing, rather than avoiding, technical debt so as to arrive at a net-positive outcome for the organization. To that end, coming up with a meaningful strategy for managing technical debt is of the essence.

Getting to grips with technical debt

Remaining responsive to external and internal demands alike is critical for maintaining an organization’s competitiveness. This requires a systematic approach to managing technical debt—and its importance only grows with the size of the organization. Unsurprisingly, tracking down the many possible types of technical debt and their complex webs presents especially large challenges at bigger companies with an IT architecture displaying complex dependencies among numerous IT systems, applied for different work processes. If the organization wishes to steer clear of becoming (further) mired in technical debt and constrained by the corresponding web of interests, creating a principled strategy is imperative. This must have clearly stated goals that aid in arranging the various activities undertaken to exploit and manage technical debt.

While the course material has supplied a sound foundation for approaching technical debt in a manner that enables making sense of its various types, their interconnectedness, and the dimensions of managing the debt, you end up thinking, “Yes, formulating a strategy to remain in the driver’s seat is indeed crucial for communicating the need to recognize technical debt and the urgency of managing it in my organization, but what would be the next concrete steps toward articulating specific strategy recommendations?” To give the organization much-needed visibility of the relevant issues and provide some direction for its efforts to orient the work around meeting your IT systems’ development and maintenance obligations simultaneously, it is best to choose a focal point—a specific IT system or work process—as a starting point for the analysis. You are pleased to find that the final part of the course-material package offers assistance via several tables (see Tables 1 –3 at the end of the teaching case) that can help you focus your analysis on identifying technical debt, evaluate their interconnectedness, and ultimately develop a strategy with specific goals. While the journey of crafting the strategy still lies ahead, the material offers numerous pointers to guide you along the way. Motivated for the path ahead, you conclude, “I’d better get another cup of coffee and then begin examining the current state of technical debt in my organization. This will certainly get me started.”

Table 1.

An outline for identifying and evaluating technical debt.

Type of technical debt	How the debt manifests itself in the system or process	Reasons for the technical debt	Consequences of the debt
Code debt (CD)
Test debt (TD)
Design debt (DeD)
Architecture debt (AD)
Requirements debt (RD)
Infrastructure debt (ID)
Data debt (DaD)
Documentation debt (DoD)
People debt (PD)
Other type of technical debt

Table 2.

A mapping table for identifying interdependencies among types of technical debt.

Type of technical debt	CD	TD	DeD	AD	RD	ID	DaD	DoD	PD
Code debt (CD)
Test debt (TD)
Design debt (DeD)
Architecture debt (AD)
Requirements debt (RD)
Infrastructure debt (ID)
Data debt (DaD)
Documentation debt (DoD)
People debt (PD)
Other type of technical debt

Table 3.

Guidance for specifying strategies aimed at managing technical debt.

Strategy	Goal(s) behind the strategy	The projects/work packages/activities encompassed	The type(s) of technical debt given focus by the strategy
Strategy #1
Strategy #2
Strategy #N

The assignment

A warm-up task: Understanding of the concept of technical debt

As discussed above, technical debt refers to future maintenance obligations of IT systems and comes in many different shapes and sizes. But what does this mean in practice? When is it a problem and when is it not? To ensure you approach this tricky subject mindfully, in this warmup task, you are asked to reflect on the topic by considering the following questions.

• What is a future IT maintenance obligation? How do you define “future” (short vs long term)? How do you define “maintenance” (keeping things running vs optimizing performance)? How do you define “obligation” (optional vs necessary)?

• How do maintenance obligations differ across different debt types? Are the types distinct or do they overlap? How might considering different types of technical debt help with identifying operational issues or maintenance needs?

• What is your risk appetite regarding technical debt? How dangerous may accruing it be for your business? Do you lean towards a vigilant or a laissez-faire approach?

• Given that IT development and implementation usually accrues technical debt in one way or the other, how do you decide when maintenance obligations become excessive? What kind of criteria could one use to assess this?

• More broadly, how do you draw a line on what is considered technical debt and what is not? Is it possible to implement a system without accruing technical debt?

• How does “the interest” of technical debt manifest? How can you tell when your past IT decisions start backfiring?

• On what level should decisions regarding technical debt be taken (executive, managerial, and operative)? How can an organization ensure continuous engagement to resolving issues related to technical debt?

There are no right or wrong answers to these questions—it all depends on your approach, business context, and unique organizational circumstances. Reflecting on these questions will ensure you have a sound understanding of the concept and are ready to tackle the following tasks.

Task 1: Analyze the state of technical debt

With the information provided, complete the following steps, referring to the tables included for guidance.

1. Decide on an area to concentrate upon in your analysis. For example, you might focus on a specific IT system used in your unit’s operations or a work process that involves interacting with multiple systems. Then, as applicable, prepare an analysis of either the IT system’s links with other IT systems and how it functions in various work processes or, in the case of a focal process, which IT systems serve that process and how.

2. Building on Step 1, identify how each type of technical debt listed in Table 1 manifests itself in the entity chosen for focus. Then, evaluate the origins or justifications for each debt type—why was it incurred in the first place and why has it not been resolved? Finally, consider the consequences of the debt for the process and/or the organization (depending on your level of analysis).

3. To deepen the analysis, work with Table 2, which provides a matrix for mapping the connections from each debt type and identify the potential interconnections among the various types. Describe the interconnectedness by populating the corresponding cell.

Task 2: Prepare a strategy for resolving the debt

With those analyses for support, prepare a strategy to manage the technical debt using Table 3 as a guide. To begin, referring to the framework in Figure 2, identify the approach which your organization has taken in the past in managing technical debt. Then, consider whether there is a need to change that approach, and if so, which one of the four approaches would you like to transition towards. Building on your chosen approach outline an ideal state of technical debt in your organization, the timeframe for reaching it, and the short- and long-term implications for the organization. Then, considering the desired state, ask which strategic goals are the most pressing for settling that technical debt. For example, you could describe the goals by way of projects each focused on a particular objective and on resolving some specific type(s) of technical debt. Thirdly, with the strategic roadmap thus outlined, assess the risks that the process could actualize and the possible beneficial outcomes, from an organization-internal and an external perspective both.

Figure 2.

A framework for managing technical debt (adapted from Fowler, 2009; Ernst et al., 2021).

Footnotes

Acknowledgements

We thank the Aalto University Executive Education for encouraging us to produce the case to be included as part of executive education on IT governance and technical debt.

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) received no financial support for the research, authorship, and/or publication of this article.

ORCID iDs

Joona Ruissalo

Tapani Rinta-Kahila

Esko Penttinen

Data Availability Statement

No data were collected in relation to this project.*

Author biographies

Joona Ruissalo is a postdoctoral researcher in information systems science at the Aalto University School of Business. He strives to understand how the development and uptake of artificial intelligence (AI) systems unfold in organizations and become to transform work practices. His research provides insight for organizations in fostering new AI capabilities by cultivating in-house technical competence to develop AI systems, transitioning to human-AI work through transformation of work roles and skills, and sustaining these new modes of value creation with apt AI governance approach. Ruissalo's research has been published in Journal of the Association for Information Systems and leading information systems conferences.

Tapani Rinta-Kahila is a senior lecturer of business information systems and an ARC DECRA Fellow at The University of Queensland Business School. Dr Rinta-Kahila’s research focuses on issues around implementing and managing AI systems in organizations, unintended consequences of AI/IT use, and decommissioning of organizational IT systems, among other topics. His research has appeared in leading IS journals, including MIS Quarterly, Journal of the Association for Information Systems, European Journal of Information Systems, Journal of Information Technology, Information & Management, and MIS Quarterly Executive.

Esko Penttinen is an Associate Professor in Information Systems at Aalto University School of Business, Finland. He studies coordination of work between humans and machines, organizational implementation of artificial intelligence, and governance issues related to outsourcing and virtual organizing. His main practical expertise lies in the development, assimilation, and economic implications of inter-organizational information systems, focusing on application areas such as electronic financial systems, government reporting, and electronic invoicing. His research has appeared in leading IS outlets such as MIS Quarterly, Journal of the Association for Information Systems, Information Systems Journal, Journal of Information Technology, Information Systems Frontiers, International Journal of Electronic Commerce, and Electronic Markets.

References

Alves

NSR

Mendes

De Mendonça

, et al. (2016) Identification and management of technical debt: a systematic mapping study. Information and Software Technology 70: 100–121.

Bray

(2015) R.B.S. is again hit by a technology failure. The New York Times. https://www.nytimes.com/2015/06/18/business/dealbook/rbs-technology-failure.html (accessed on 4 April 2024).

Burden

Van Der Ouderaa

Venkataraman

, et al. (2018) Technical debt might be hindering your digital transformation. MIT Sloan Management Review 60(1): 1–5.

Cooban

(2024) Prison. Bankruptcy. Suicide. How a software glitch and a centuries-old British company ruined lives. CNN. https://edition.cnn.com/2024/01/13/business/uk-post-office-fujitsu-horizon-scandal/index.html (accessed on 4 April 2024).

Cunningham

(1992) The WyCash portfolio management system. In: Proceedings on object-oriented programming systems, languages, and applications (addendum), Vancouver, BC, 18–22 October 1992, 29–30.

Devico (2024) Technical debt examples and how to solve them. https://devico.io/blog/technical-debt-examples-and-how-to-solve-them (accessed on 8 April 2024).

Ernst

Kazman

Delange

(2021) Technical Debt in Practice: How to Find it and Fix it. Cambridge, MA: MIT Press.

Fowler

(2009) Technical debt quadrant. https://martinfowler.com/bliki/TechnicalDebtQuadrant.html (accessed on 17 April 2024).

Avgeriou

Liang

(2015) A systematic mapping study on technical debt and its management. Journal of Systems and Software 101: 193–220.

10.

Mäki

Penttinen

Rinta-Kahila

(2023) A domino effect: interdependencies among different types of technical debt. In: Proceedings of the 56th annual Hawaii international conference on system sciences, Honolulu, HI, 3–6 January 2023, 5949–5958.

11.

Martini

Bosch

Chaudron

(2015) Investigating architectural technical debt accumulation and refactoring over time: a multiple-case study. Information and Software Technology 67: 237–253.

12.

Merriam-Webster (2024) Debt. Merriam-Webster.com dictionary. https://www.merriam-webster.com/dictionary/debt (accessed on 15 April 2024).

13.

Ramasubbu

Kemerer

(2016) Technical debt and the reliability of enterprise software systems: a competing risks analysis. Management Science 62(5): 1487–1510.

14.

Rinta-Kahila

Penttinen

Lyytinen

(2023) Getting trapped in technical debt: sociotechnical analysis of a legacy system’s replacement. MIS Quarterly 47(1): 1–32.

15.

Rolland

Lyytinen

(2021) Managing tensions between architectural debt and digital innovation: the case of a financial organization. In: Proceedings of the 54th Hawaii international conference on system sciences, Kauai, HI, 5 January 2021, 6722–6737.

16.

Rolland

Mathiassen

Rai

(2018) Managing digital platforms in user organizations: the interactions between digital options and digital debt. Information Systems Research 29(2): 419–443.

17.

Treanor

(2014) RBS fined £56m for IT breakdown. The Guardian. https://www.theguardian.com/business/2014/nov/20/royal-bank-of-scotland-it-breakdown-56m-pounds-fine (accessed on 4 April 2024).

18.

Vuori

Huy

(2015) Distributed attention and shared emotions in the innovation process: how Nokia lost the smartphone battle. Administrative Science Quarterly 61(1): 9–51.