Abstract
This teaching case provides a simple yet comprehensive overview of Technical Debt (TD) and its associated terminology to the readers. TD, which has received an increasing amount of attention from information systems (IS) development research and practice, is mainly used to communicate the consequences of sub-optimal design decisions and trade-offs made during software development with non-technical project stakeholders. We reviewed the extant literature and interviewed five software professionals from a European company to examine this costly phenomenon. As such, we provide a comprehensive understanding of TD, its relevant terminology, and concrete examples that can help information systems and business students better understand the topic. In addition, the teaching case demonstrates antecedents, benefits and challenges, and the responsibilities associated with the accumulation of TD. We argue that, unfortunately, the moral responsibility associated with TD tends to get diffused leading to the invisibility of consequences and de-individuation issues in software teams. To this end, considering the critical role of software-intensive systems in modern societies, we argue that practitioners should look beyond the financial or technical costs and benefits of TD and consider the ethical and societal responsibilities associated with its accumulation carefully.
Keywords
Introduction
In information systems (IS) development projects, often teams decide to take shortcuts and make sub-optimal decisions to catch a deadline, shorten the time to market, or test the market-fit of an innovative solution (Ghanbari et al., 2018). In other words, they decide to deliver a sub-optimal product now and if needed fix it later. Delivering a sub-optimal product, however, may come at the expense of system quality and future financial costs. When such quality-compromising shortcuts and trade-offs are made with the knowledge that they will accumulate future maintenance obligations, a development team is said to incur Technical Debt (TD).
TD was originally coined as a metaphor to explain the consequences of delivering not-quite-ready code (Cunningham, 1992). However, in recent years it has been used to communicate the issues in different artifacts produced during software development processes. Like financial debt, software development teams can benefit from taking on TD to deal with lack of resources. Similar to financial debt, however, the inability to repay TD could have dire consequences and burden a firm to the point of threatening its future operations. Therefore, while taking on TD, development teams must consider the number of benefits they will gain compared to the total amount of costs that they will have to pay in the future.
Used wisely, TD allows development teams to achieve their short-term and long-term goals. For instance, a development team facing resource constraints could postpone certain tasks such as code review or documentation to later iterations to achieve the short-term goal of on-time delivery of a release. On the other hand, another team may decide to alter the design of their product (e.g., instead of creating a multi-platform architecture, build a native app) to achieve the long-term goal of capturing market share in an emerging market. Tech companies have traditionally followed such a strategy by releasing not-quite-ready products to capture market share and releasing frequent updates to improve those products.
However, by taking on TD, development teams postpone some of the costs and efforts necessary for developing an artefact in the future. These costs could resurface during the later stages of a product’s lifecycle and lead to extra complications during maintenance. Consequently, if TD is left unmanaged, it might prove too costly for a firm.
Previous studies have mostly examined the negative impact of TD on software quality and an organization’s digital innovation capability (Adam et al., 2018; Asatiani and Torell, 2023), except for a small number of studies that have examined its behavioral aspects (Besker et al., 2020). However, surprisingly, the research has overlooked a significantly important issue: the consequences of sub-optimal design decisions for end-users and society. For instance, in the case of the Vastaamo psychotherapy clinic, software systems handling patients’ sensitive personal information was developed by an incompetent developer, and the vulnerabilities introduced during the process eventually led to one of the biggest data breaches in Finnish history (Ghanbari and Koskinen, 2024). Therefore, considering that design decisions made during software development projects can impact and shape a significantly large number of users, it is crucial to pay more attention to the ethical and societal impacts of sub-optimal decisions made by developers as a result of which TD is incurred.
What is TD?
In 1992, Cunningham (1992) introduced TD as a metaphor for communicating the consequences of delivering immature code which enables organizations to shorten their delivery times: “Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite” (Cunningham, 1992: 30).
Types of technical debt incurred during different stages of SDLC.
Thus, TD can accumulate for different reasons, by different parties, and in different artefacts throughout the life cycle of a product. Since these artifacts are often transferred between developers or development teams, and used as a basis for subsequent development steps, it is crucial to identify and manage TD throughout the system development life cycle.
Terminology of TD
It may occasionally be necessary for organizations to intentionally incur TD (Brown et al., 2010; McConnell, 2007). However, since TD accumulates extra maintenance costs, it has to be taken consciously and managed properly (Kruchten et al., 2012) or else it can have devastating costs and consequences for organizations. To emphasize the increased maintenance costs of TD over time, along similar lines as financial debt, principal and interest are two terms that have been used by previous studies (Alves et al., 2015; Li et al., 2015). Other terms such as debt ratio (McConnell, 2007; Tom et al., 2012), debt amnesty or retiring (Alves et al., 2015; Tom et al., 2013), and bankruptcy (Tom et al., 2012) have also been used to discuss consequences of TD.
The principal is the amount of effort needed to perform a task which was left to be done later (Alves et al., 2015). In other words, the principal is the amount of effort needed for resolving a single TD item. Interest is the potential penalty of TD in terms of additional maintenance costs and effort needed to spend in future until a TD item is completely resolved (Tom et al., 2012). Such extra maintenance costs are incurred as too much short-term TD leads to higher levels of deficiency and systems complexity (Elbanna and Sarker, 2016) which, in turn, leads to unexpected delays and lower productivity (Elbanna and Sarker, 2016). TD principal and interest are even more problematic in bigger projects where a larger number of developers are working with the system simultaneously, and where the increased complexity makes it difficult and sometimes nearly impossible for them to patch and maintain the software over time.
Therefore, the incurred TD have to be managed properly to maintain the quality of the project in the long run (McConnell, 2007). TD management consists of all the activities enabling organizations to identify, track, analyze, and repay different instances of TD (Li et al., 2015). For instance, when developers decide to omit certain tests in an attempt to quickly release new features required by customers, they have to document that quality control TD and ensure that it is repaid in future releases by properly testing those features. To reduce the amount of interest, organizations either should pay down the principal by refactoring or redesigning the product or might retire the TD by abandoning the artefacts containing TD.
In case the ratio of TD to design capital is too high, an organization may need to pay an overwhelming amount of interest to maintain a system and keep it operational. In such situations, bankruptcy happens when extending the capabilities of a system or improving its performance is no longer practical (McConnell, 2007; Tom et al., 2013), and, as a result, system development comes to a halt. Therefore, it makes more sense for the firm to retire the TD either by fully rewriting or redesigning a module or even a whole system or by abandoning the artefacts containing TD (Tom et al., 2012, 2013).
However, in some cases paying TD accumulated in a system or its components becomes unnecessary. This is called TD amnesty (Tom et al., 2013). Amnesty often happens when a system or any of its components are discarded because it is not supposed to become operational (e.g., throwaway prototypes), it fails to fulfill its original objectives (e.g., abandonware such as Microsoft Bob), or its service life comes to an end (McConnell, 2007; Tom et al., 2013).
How is TD accumulated?
TD can accumulate for different reasons, by different parties, and in different artefacts throughout the life cycle of a digital product. As such, TD accumulation can be explained in terms of the focus of TD, the intentions underlying TD or the reasons behind its occurrence. In terms of focus, TD could be divided into product-centric or process-centric TD. While product-centric TD points to issues in certain software artefacts (e.g., code, test scripts or documents) that must be fixed, process-centric TD addresses certain tasks (e.g., code review, automated tests, or updating documents) that may be skipped.
In terms of intentions, TD can be incurred intentionally or unintentionally (Tom et al., 2013). Unintentional TD is the result of unwise or inadvertent decisions made during system development processes. This type of TD is incurred due to oversight, lack of experience, or insufficient knowledge about the consequences of specific development decisions. For instance, a software tester might write bad test scripts, a designer might choose a sub-optimal architecture, or a development team might decide to use a third-party component which contains some TD. Intentional TD, however, is the result of conscious business decisions made by organizations to gain short-term benefits—such as increased velocity or reduced resource consumption (Alves et al., 2015). In such situations, quality practices are neglected to deal with urgent demands usually imposed by external factors within the environment. The most common demands reported in the literature are time pressure and resource constraints (Ghanbari et al., 2018).
Depending on the reason behind its occurrence, we divide intentional TD into strategic and incremental sub-types, where strategic TD is incurred by the organization for a specific purpose, while incremental is incurred by individual developers as a result of intentional non-compliance with rules. Strategic TD refers to proactive or reactive trade-offs made by organizations to cut development time and costs for strategic reasons, such as capturing market share (Tom et al., 2013), preserving the firm’s capital or delaying development expenses (McConnell, 2007). Taking on this type of TD is considered crucial for an organization’s business continuity (Tom et al., 2013). For instance, imagine that to launch their mobile app as soon as possible and based on the assumption that they will not support other platforms shortly, a software firm decides to design their app only for the iOS platform. In this case, the firm strategically decides to postpone the development costs of supporting multiple platforms for a few years to capture market share as soon as possible and ensure enough revenue to grow its business. In some cases, companies might take on TD reactively, often to speed up delivery to gain some short-term benefits, such as fulfilling contractual obligations and receiving payments (McConnell, 2007; Tom et al., 2013). For instance, imagine that in a software start-up, developers, facing a lack of time, decide to skip planned automated tests or code reviews to release a feature on time. In other words, tactical TD is about buying some time by taking shortcuts and “to get a specific release out the door” (McConnell, 2007).
Strategic TD accumulated by firms is often sizable and more distinct and, as a result, it is easier to identify and manage. It is often paid back in the long term since development costs in the future are considered to be cheaper than today (McConnell, 2007).
Incremental TD consists of large numbers of small shortcuts consciously taken by individual developers on a daily basis, often to get the work done quickly (McConnell, 2007; Tom et al., 2013). For instance, a developer consciously ignores coding standards or postpones writing comments. Like using a credit card for micro-purchases, this type of TD piles up easily and quickly, but is hard to manage (McConnell, 2007). Since it does not have any short- or long-term benefits and on the contrary, it is a major source of extra maintenance costs, incremental TD should be avoided altogether (McConnell, 2007).
Given the role that TD could play in helping development teams achieve their goals or spoiling their future operations, it is of utmost importance that teams take on TD strategically and manage it appropriately to gear towards their goals and visions. Taking on TD enables organizations to preserve their development resources and increase their competitiveness. This strategy gains prominence, particularly for developing a Minimum Viable Product (MVP), which just has enough features to gather feedback from its users and customers. Accumulating TD plays an important role in developing MVPs as it enables firms to quickly develop and test an innovative idea or business model with minimal costs and effort. On one hand, if the MVP turns out to be a failure, firms could safely abandon the product and retire the debt. On the other hand, if the MVP is successful, the accumulated TD could transfer into the commercial end product and cause extra maintenance obligations. Therefore, organizations shall take on TD as a painkiller to remedy their constraints, while avoiding accumulation of unnecessary TD.
Insights gained from the case study
Interviewees information.
As explained in previous sections, TD is the result of trade-offs in which developers postpone something to be done in the future, for instance, to deal with resource constraints. “Testing and documentation suffer the most. They're the first things getting out of the way… you start cutting at the end.” - Software Developer 1
Even though reactively taking on TD can be considered a short-term solution to resource constraints, taking on TD proactively can be seen as a means for testing new ideas and performing experiments. In such cases, by using prototypes or delivering a MVP to market quickly, firms can observe users’ experience, and gather feedback from their customers to improve their products and services. Such experimentation is not limited to testing an idea or identifying the right set of features to be implemented, but it can be also used by firms to test their business model. This is especially beneficial during the early phases of product development since firms can benefit from TD amnesty and avoid TD repayment by abandoning a feature based on users’ experience or discontinuing a product that is considered unprofitable: “We also prototype things to see what works and what not and if it doesn't work find out why not. and if we think it's not going to work we stop that and focus on what works.” - Software Developer 2
In other words, in such cases, TD can be seen as a grant with no interest or liabilities rather than a debt which must be paid back. This can be very beneficial for firms in avoiding the risk of wasting their limited resources when they are not certain about an innovative idea or feature.
While intentionally taking on the right type and amount of TD enables firms to deal with resource constraints and uncertainties, interviewees agreed that incremental TD should be avoided since it is a major source of extra maintenance costs and efforts. Developer’s lack of attention or as some called ignorance seems to be the main reason behind the accrual of incremental TD: “There are people who really don't care much about what they're doing but just want to go home when the time finishes, they don't bother about the quality of delivery.” - Team Lead 1
In addition to avoiding unwanted TD, proper TD management enables firms to improve their knowledge base and competencies as well as their development processes. Our interview data shows that identification and repayment of TD, through code reviews and refactoring, enables developers, especially novice ones, to learn about their mistakes and improve their skills and knowledge accordingly. A team leader (i.e., Team Lead 1) mentioned that by performing code reviews, they can avoid the future consequences of TD and at the same time encourage individual developers to improve their skills. Another senior software architect and team leader suggested that enforcing coding guidelines best practices and performance reviews to evaluate compliance with those guidelines not only enables them to avoid TD but also to: “Help new developers learn their own responsibilities because young developers usually don’t have a notion of responsibility.” - Senior Software Architect
In other words, by learning from their past experiences and mistakes, firms are able to increase their developers’ knowledge and awareness. This is especially beneficial to avoid unintentional and incremental TD, which is often accumulated due to a lack of attention and competency or the developer’s ignorance.
As explained before, TD is the result of quality-compromising trade-offs or sub-optimal decisions made to minimize development costs and delivery time. The idea is to deliver a good enough artefact as soon as possible and improve its quality in the future. However, addressing quality issues in the future is not easy and straightforward. The difficulty in repaying TD and software maintenance in the future is mentioned by a senior test engineer in the following excerpt: “I may have ignored some Unit-Tests in the development and I think, well the code seems to be good, this will work, let's put it in production. But when I get back to that code in the future I realise that I should have enforced some best practices.” - Team Lead 2
Software firms have to spend an extra amount of resources to address maintenance and scalability issues caused by TD to improve their products. If these extra costs outweigh the benefits that firms gain, TD is not beneficial. This is especially the case when firms have to service their TD only to be able to keep their products operational. Accumulation of large amounts of architectural debt and test debt could make it very difficult to scale and extend a piece of software in the future. In extreme cases, a firm might face a dilemma in which repaying TD could risk breaking other parts of the code or introducing more TD or bugs while avoiding TD payback could just as well lead to ever more accumulation of TD until product development becomes impossible or extremely costly. Such a scenario could bring about huge economic costs as it can force the firm to redesign or rewrite the whole product.
Customer experience is another aspect that could be negatively influenced by the quality issues associated with the accumulation of large amounts of TD or unmanaged TD. For instance, if a bug that is caused by TD pops up in production, it can lead to a negative user experience; it may reduce customer satisfaction or influence the image of a firm. Thus, in case TD is not taken carefully or managed properly, it may lead to a loss of market share rather than an increase in market share.
Finally, a large amount of TD, especially when it is unmanaged, can reduce developers' morale and productivity. As discussed earlier, the accumulation of TD makes it challenging for software developers to maintain and extend software. Especially, when firms are growing fast, in addition to dealing with resource constraints, developers have to cope with constant improvement requests to accommodate market demands. This could put developers under pressure and could negatively influence their confidence.
Reflection on the case and the literature
To summarize our observations from the literature and the interviews with software professionals, it can be concluded that for a firm to leverage the advantages of TD, it must be taken intentionally and for good tactical or strategic reasons. This enables firms to deal with different problems (e.g., lack of funds and resources, uncertainty about their products and market, immature development teams, and processes) and capture market share with a minimal amount of resources. However, upon its occurrence, TD must be managed properly to control its costs and consequences. If taken recklessly and left unmanaged TD can lead to severe quality issues that could make product maintenance and scalability extremely difficult and costly in the long run. Such issues not only influence productivity and progress but also have the potential to lead to significant financial loss and loss of customers. Thus, firms must avoid the accumulation of unintentional or incremental TD which do not add value.
One noticeable observation we made during our literature review and the interviews with the software professionals we realized that research and practice have mostly focused on the quality, productivity, and financial costs of TD for the companies while overlooking the impact and consequences of TD for users and customers.
In many cases, developers might accumulate certain types of incremental TD that do not have a huge impact on the users and stakeholders. For example, writing comments in the code or preparing documentation for the code, is often seen as a less important and laborious task by many developers and therefore ignored leading to documentation debt. However, even this “less important” type of TD can impact other practitioners who need to work with the code in the future. More importantly, such mentality and avoiding responsibility in such less demanding tasks can become a habit and developers start taking shortcuts during more crucial tasks such as testing and quality control. This can ultimately lead to situations where software professionals and companies make questionable or sub-optimal design decisions and other stakeholders (e.g., customers and users) end up paying for those decisions and their consequences, which is against fairness.
Unlike financial debt, repaying TD and dealing with its consequences can become the responsibility of teams or firms that had nothing to do with its accumulation, which compromises fairness as a fundamental principle in any IS development project (Chatterjee et al., 2009). Therefore, to ensure fairness, when taking on TD we must consider and visualize the long-reaching costs and consequences of TD for various stakeholders and avoid de-individuation and loss of personal responsibility among software developers (Chatterjee et al., 2009). Considering the critical role of software-intensive systems in modern societies, software professionals should take more responsibility for the consequences of their decisions and their broader impacts on society and the environment (Venters et al., 2018). Following this line of thinking we urge practitioners and software firms to look beyond the financial costs and benefits of TD and consider the ethical and societal responsibilities associated with its accumulation carefully. In so doing, they must enact moral responsibility towards other stakeholders of the process (e.g., consumers, customers, and society). However, unfortunately this is challenging as information technology is known to cause distanciation between developers who develop software and the users of the software, or any other stakeholders affected by the use of software (Chatterjee et al., 2009). As a result, the moral responsibility associated with design decisions and software artefacts tends to get diffused leading to the invisibility of consequences or de-individuation (Chatterjee et al., 2009).
On the one hand, the invisibility of temporally and spatially remote consequences of design decisions, and how they can affect users or other stakeholders in the future, makes it easy for developers to dismiss the negative consequences of their decisions as not being relevant or important. On a daily basis, when developers need to make quick decisions, they might not think carefully about the consequences of accumulating TD, for instance, by skipping certain coding or testing tasks, in the long run. This becomes problematic, especially in a fast-paced environment where the overall team or firm culture might encourage more rapid development and delivery of code and other software artefacts. Our experience from other projects shows that software developers often justify their decisions by downgrading the probability or impact of their sub-optimal decisions. Such behavior or mindset can impact a team or firm’s quality culture and have consequences in the long run. Developers can become emotionally and cognitively separated from their decisions and artefacts they design and as a result lose personal ownership of the outcome (Chatterjee et al., 2009).
On the other hand, de-individuation emerges when practitioners lose their sense of personal accountability as their voices are submerged in a collective voice representing the organization. For example, developers might argue that they take on TD under pressure from the sales and business units or as a result of decisions made by the management or they simply implement the decisions made by others. Alternatively, they might argue that their job ends as soon as the artefact is passed to quality control or operations, and dealing with a software problem that occurred in testing or operations is not their responsibility. While some decisions are made at the organizational level and must be considered from a business ethics perspective, software professionals are the ones who decide how to implement these decisions (Gogoll et al., 2021).
To conclude, we propose that organizations as well as the academic and professional communities must actively promote a culture of responsibility in which software professionals take ownership of their decisions and their outcomes. This in turn can help increase practitioners’ moral sensitivity and encourage them to engage in proper ethical deliberation when making design decisions and trade-offs, which can help mitigate the accumulation of unwanted TD.
Discussion questions
1. How are the antecedents of TD accumulation different in a software start-up compared to a large organization? 2. How are the benefits of TD different for a software start-up compared to a large company? 3. How can the accumulation of TD hinder a software start-up’s growth? 4. How can the accumulation of TD hinder a large organization’s digital innovation capability? 5. If you were a software team lead, which types of TD would you avoid? Why? 6. How can you, as a software team lead, avoid unnecessary accumulation of TD? 7. Can you think of any moral and ethical consequences related to the accumulation of TD? If yes, how should we address those consequences? 8. Who should be held accountable for the accumulation of TD during digital innovation processes?
Footnotes
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.
