Article

An exploration of technical debt

Authors:
  • Sydney, Australia
To read the full-text of this research, you can request a copy directly from the authors.

Abstract

ContextWhilst technical debt is considered to be detrimental to the long term success of software development, it appears to be poorly understood in academic literature. The absence of a clear definition and model for technical debt exacerbates the challenge of its identification and adequate management, thus preventing the realisation of technical debt's utility as a conceptual and technical communication device.Objective To make a critical examination of technical debt and consolidate understanding of the nature of technical debt and its implications for software development.Method An exploratory case study technique that involves multivocal literature review, supplemented by interviews with software practitioners and academics to establish the boundaries of the technical debt phenomenon.ResultA key outcome of this research is the creation of a theoretical framework that provides a holistic view of technical debt comprising a set of technical debts dimensions, attributes, precedents and outcomes, as well as the phenomenon itself and a taxonomy that describes and encompasses different forms of the technical debt phenomenon.Conclusion The proposed framework provides a useful approach to understanding the overall phenomenon of technical debt for practical purposes. Future research should incorporate empirical studies to validate heuristics and techniques that will assist practitioners in their management of technical debt.

No full-text available

Request Full-text Paper PDF

To read the full-text of this research,
you can request a copy directly from the authors.

... TD provides software development teams with the flexibility to release IT applications in a timely way by de-prioritising or postponing some actions to make room for more pressing ones (Rolland et al., 2018). However, excessive or uncontrolled TD or lack of awareness about its effects may affect an organisation's IT landscape negatively in the long run (Tom et al., 2013) by creating quality issues and increasing the cost of IT evolution (Ramasubbu & Kemerer, 2016;Woodard et al., 2013). Consequently, TD must be managed in such a way that it remains at a controllable level; the goal is not to eradicate TD but to manage it strategically. ...
... Inherent to TD is a trade-off between momentary benefits and future liabilities (Rolland et al., 2018). While incurring TD lends software development teams the leeway to meet business expectations (Kruchten et al., 2019;Siavvas et al., 2022), such as quickly and efficiently releasing novel IT applications (Li et al., 2015;Tom et al., 2013), excessive and uncontrolled levels of TD may be harmful to an organisation's IT landscape in the long run (Ramasubbu & Kemerer, 2016;Woodard et al., 2013). Incurring TD may result from carrying out tasks inadequately and making decisions that have short-term benefits but require significant maintenance later (Rios et al., 2018). ...
... Incurring TD may result from carrying out tasks inadequately and making decisions that have short-term benefits but require significant maintenance later (Rios et al., 2018). Numerous small shortcuts that add up to TD can yield uncontrollable TD levels and negative consequences (Ramasubbu & Kemerer, 2016;Woodard et al., 2013), such as reduced productivity, quality issues, and premature loss of a system Tom et al., 2013;Yli-Huumo et al., 2016). ...
Article
Full-text available
Technical debt (TD) is a technical compromise wherein the ability to maintain information technology (IT) applications over the long term is sacrificed for short-term goals. TD occurs when software development teams undergo constant pressure to release applications swiftly, on a tight schedule. The accumulation of TD, which often leads to a significant cost surplus, presents a ubiquitous challenge in technology-driven organisations. To keep TD levels under control, many organisations implement top-down mechanisms that impose enterprise-wide principles on software development teams. This clinical research presents a complementary but distinct approach to managing TD. A digital nudge was introduced at Credit Suisse, a global financial services company, to help raise awareness and understanding, and stimulate actions related to TD decision-making in software development teams. This paper reports on the nudge’s clinical design, implementation, impact, and evaluation. As the nudge was effective in reducing TD in IT applications after one year of use, we demonstrate that digital nudges are viable means for guiding collective decisions in complex decision environments like that of TD management. Our findings have several implications for research and practice.
... Intentionally incurring TD to achieve short-term benefits can be advantageous if the debt is managed properly [1,22]. Managing TD presents substantial challenges related to the abstract nature of the term, such as quantifying, visualising, and even agreeing on what TD is [36]. Still, little research has been done on how software developers view TD, even though this perspective is vital to enable developers to effectively manage TD [16,22]. ...
... Since then, a wide range of definitions has been suggested by several authors, often expanding the definition to a more widespread and general perspective on software development costs, including architectural, testing, or documentation related TD. As a consequence of the absence of a singular definition, researchers have argued that the metaphor may be losing some of its strength [18], as it exacerbates the challenge of identifying and managing the debt adequately [36]. However, the consensus on the term is that it describes trade-offs between some expedient short-term decisions and the resulting long-term costs [21,22]. ...
... Understanding and managing Technical Debt (TD) has been a research interest for the past three decades [7], with multiple studies explaining the TD metaphor [12,17,18,36] and discussing the use of different TD management strategies [1,4,38]. However, few studies have been conducted using the Action Research (AR) approach [28,39], and none have to our knowledge taken the approach of incorporating deliberation theory. ...
Chapter
Technical Debt (TD) has seen a growing interest from software companies and researchers since the term was first established almost 30 years ago. TD refers to concessions made for short-term advantages or conveniences, which may result in long-term difficulties. Numerous TD management strategies have been proposed to avoid the severe consequences of leaving TD unchecked. However, these strategies often suffer from being too abstract, making it difficult to initiate TD deliberations. To investigate how software development companies can initiate such deliberations, we conducted an Action Research study in collaboration with a Danish software development department, SoftShelf. Through two Action Research interventions at SoftShelf, we introduced strategies and tools for TD management and reified them to their situation in order to initiate deliberations on the matter. After reporting the interventions’ practical consequences in SoftShelf, we discuss the usefulness of deliberation theory in TD management research and practice.
... Data from several secondary studies reveal that few TD studies have investigated the relationship between TD and human aspects (Tom et al. 2013;Li et al. 2015;Ampatzoglou et al. 2015;Alves et al. 2016;Fernȧndez-Sȧnchez et al. 2017;Besker et al. 2018a). Rather, the predominant concerns have been technical and financial aspects, e.g., software quality or cost of future changes. ...
... When human aspects are addressed in TD research, the most frequently investigated topic is morale. A negative correlation was proposed early by Tom et al. (2013) based on anecdotal evidence found in web blogs. Since then, empirical investigations have corroborated the connection, including previous articles of our own, see (Besker et al. 2020). ...
... These results are corroborated by F13, F16, F17, and F22; and F15 and F19, respectively. Hence, we provide further evidence in favor of the long-held belief that morale and TD are intertwined (Tom et al. 2013;Spínola et al. 2013). ...
Article
Full-text available
Context Software engineering is a human activity. Despite this, human aspects are under-represented in technical debt research, perhaps because they are challenging to evaluate. Objective This study’s objective was to investigate the relationship between technical debt and affective states (feelings, emotions, and moods) from software practitioners. Method Forty participants ( N = 40) from twelve companies took part in a mixed-methods approach, consisting of a repeated-measures ( r = 5) experiment ( n = 200), a survey, and semi-structured interviews. From the qualitative data, it is clear that technical debt activates a substantial portion of the emotional spectrum and is psychologically taxing. Further, the practitioners’ reactions to technical debt appear to fall in different levels of maturity. Results The statistical analysis shows that different design smells (strong indicators of technical debt) negatively or positively impact affective states. Conclusions We argue that human aspects in technical debt are important factors to consider, as they may result in, e.g., procrastination, apprehension, and burnout.
... As will be further discussed in the following section, from an inspection of the related literature, not all activities of the TD research result to be studied with the same intensity. In particular, several gaps of research can be identified by considering the secondary studies concentrating on TD [10,11,9,4,5,12]. From such studies several TD related activities result to be lacking the required depth and in some cases remain 5 ...
... In fact, while Code TD has been studied for many years [38], other types of TD result to date to be fairly young research fields, that were only studied in the most recent years [4]. Nevertheless, as pointed out by all the secondary studies on TD present in the literature [10,11,9,4,5] TD related analysis cannot be carried out at code level alone, as some TDIs can be identified exclusively by considering higher levels of abstraction. ...
... Regarding the current research gaps of TD, a first consideration has to be made on understudied or inexplored TD types. Fortunately, from the secondary studies considered, we can evince that the results regarding the less explored areas of TD are consistently reported in the literature [10,11,9,4,5]. From such results, we can evince that the following areas of research result to date to be only mentioned or marginally explored: People TD, Requirements TD, Documentation TD, Service TD, and Versioning TD. ...
Thesis
Full-text available
Architectural technical debt (ATD) in a software-intensive system is the sum of all design choices that may have been suitable or even optimal at the time they were made, but which today are significantly impending progress: structure, framework, technology, languages, etc. Unlike code-level technical debt which can be readily detected by static analysers, and can often be refactored with minimal or only incremental efforts, architectural debt is hard to detect, and its remediation rather wide-ranging, daunting, and often avoided. The objective of this thesis is to develop a better understanding of architectural technical debt, and determine what strategies can be used to identify and manage it. In order to do so, we adopt a wide range of research techniques, including literature reviews, case studies, interviews with practitioners, and grounded theory. The result of our investigation, deeply grounded in empirical data, advances the field not only by providing novel insights into ATD related phenomena, but also by presenting approaches to pro-actively identify ATD instances, leading to its eventual management and resolution.
... TD can be perceived as debt 'borrowed' by technology staff on behalf of their organisations. It is presented in the literature as emanating from decisions made by technologists where: (i) decisions are made in isolation from the rest of the company [2], [3]; (ii) the impact of decisions may be invisible to those outside IT [4]; (iii) the impacts can cause constrained options for future growth through increased costs [2], [5]- [7], operational risk [8], staff issues [9], [2], [10], [7] and ethical challenges [11], [12]; and (iv) in extreme cases, the impacts can be a threat to the very existence of a company [8], [13]. ...
... TD can be perceived as debt 'borrowed' by technology staff on behalf of their organisations. It is presented in the literature as emanating from decisions made by technologists where: (i) decisions are made in isolation from the rest of the company [2], [3]; (ii) the impact of decisions may be invisible to those outside IT [4]; (iii) the impacts can cause constrained options for future growth through increased costs [2], [5]- [7], operational risk [8], staff issues [9], [2], [10], [7] and ethical challenges [11], [12]; and (iv) in extreme cases, the impacts can be a threat to the very existence of a company [8], [13]. ...
... TD can be perceived as debt 'borrowed' by technology staff on behalf of their organisations. It is presented in the literature as emanating from decisions made by technologists where: (i) decisions are made in isolation from the rest of the company [2], [3]; (ii) the impact of decisions may be invisible to those outside IT [4]; (iii) the impacts can cause constrained options for future growth through increased costs [2], [5]- [7], operational risk [8], staff issues [9], [2], [10], [7] and ethical challenges [11], [12]; and (iv) in extreme cases, the impacts can be a threat to the very existence of a company [8], [13]. ...
Conference Paper
Full-text available
Technical Debt (TD) is a widely discussed metaphor in IT practice focused on increased short-term benefit in exchange for long-term ‘debt’. While it is primarily individuals or groups inside IT departments who make the decisions to take on TD, we find that the effects of TD stretch across the entire organisation. Decisions to take on TD should therefore concern a wider group. However, business leaders have traditionally lacked awareness of the effects of what they perceive to be ‘technology decisions’. To facilitate TD as group- based decision-making, we review existing literature to develop a typology of the wider impacts of TD. The goal is to help technologists, non-technologists, and academics have a broader and shared understanding of TD and to facilitate more participatory and transparent technology-related decision making. We extend the typology to include a wider ‘outside in’ perspective and conclude by suggesting areas for further research.
... L'inertie socio-technique est liée à la propension des systèmes, composés d'acteurs et de technologies, à poursuivre sur leur même trajectoire. L'analyse de la revue de littérature évoque le manque de compétences comme facteur déclencheur de la dette ; il est lié principalement à l'incapacité à maintenir un bon niveau de qualité Tom et al., 2013 ;. ...
... Tom, E., Aurum, A., & Vidgen, R. (2013). An exploration of technical debt. ...
Conference Paper
Full-text available
Les innovations rapides et les avancées technologiques obligent les entreprises à accélérer leur transformation numérique afin de s'adapter au besoin du marché et d'assurer leur pérennité. Cependant, cette accélération ne doit pas se faire au détriment de certains risques liés à l'accumulation de la dette technique. En effet, un développement rapide associé aux approches de développement de plus en plus agiles largement adoptées au sein des entreprises du numérique, peut potentiellement favoriser l'endettement technique et entraîner ainsi des dysfonctionnements majeurs qui risquent d'entraver l'évolutivité du système à plus long terme. L'objectif de cette étude est de construire, à partir de la littérature existante, un modèle explicatif du phénomène de la dette technique dans le contexte Agile. Nous analysons ainsi l'impact de ce contexte de développement sur la production de la dette technique et nous identifions les contraintes inertielles qui entravent sa bonne gestion. Pour ce faire, nous avons mené une revue de littérature dans laquelle nous avons mobilisé la méthode inductive BIBGT, qui se base sur la combinaison de techniques bibliométriques avancées et de la Grounded Theory. Nous identifions à travers cette revue de littérature par ailleurs les différentes écoles de pensée, les différentes thématiques du front de recherche ainsi que les principales pistes de recherche qui nous permettraient d'améliorer notre compréhension sur le phénomène de la dette technique.
... However, the startup may be driven off course in the process by piling up TD. This delays the advancement of new features, raises difficult quality issues and undermines team morale (Tom et al. 2013). Common complaints from customers concern functional mistakes in mobile applications, slowness in normal use, and unexpected crashing of applications (Khalid et al. 2014). ...
... Startups may transform the TD into an investment in which the payback time never arrives. Tom et al. (2013) call this "debt amnesty," which happens when the feature or product does not succeed. Further, Avgeriou et al. determined that TD is: ...
Thesis
Full-text available
Over the last 20 years, a very large number of startups have been launched, ranging from mobile application and game providers to enormous corporations that have started as tiny startups. Startups are an important topic for research and development. The fundamentals of success are the characteristics of individuals and teams, partner investors, the market, and the speed at which everything evolves. Startup’s business environment is fraught with uncertainty, as actors tend to be young and inexperienced, technologies either new or rapidly evolving, and team-combined skills and knowledge either key or fatal. As over 90% of software startups fail, having a capable and reliable team is crucial to survival and success. Many aspects of this topic have been extensively studied, and the results of the study on human capital are particularly important. Regarding human capital abilities, such as knowledge, experience, skills, and other cognitive abilities, this dissertation focuses on design skills and their deployment in startups. Design is widely studied in artistic and industrial contexts, but its application to startup culture and software startups follows its own method prison. In the method prison, old and conventional means are chosen instead of new techniques and demanding design studies. This means that when a software startup considers design as a foundation for creativity and generating better offerings, they can grab any industry with a disruptive agenda, making anything software-intensive. The concept of design can be expanded and deepened to a new level. Business can escape the method prison if it adopts artistic design to help stagnant industries and uses disruptive methods with realistic self-efficacy. Through five partially overlapping articles with varying details, this dissertation clarifies the daily themes and interests of startups required to survive and succeed. This dissertation is a reflective practitioner’s investigation of startup practices using a mixed-methods approach. With design-based creativity, startups will be stronger and more successful in the future. They can cause or protect themselves from disruption. Startup can retain customers and its self- efficacy strengthen.
... On the other hand, AK management is challenging in agile GSE since knowledge management is a challenge too [33][34][35]. Knowledge capturing is a critical phase of the AK management process in agile GSE environment [36]; however, the agile developers' attitudes [37] towards this phase cause documentation debt [11]. Since an agile GSE environment leads to a lack of captured AK, the knowledge management phases of sharing/disseminating and acquiring/applying are also affected because AK is shared and acquired based on inappropriate documentation or even tacit knowledge. ...
... In addition, there generally exists time pressures in agile GSE environments [36], and developers show a lousy attitude towards documentation [37]. These situations generate documentation debt [11], which is addressed by constantly interacting between remote and local team members via UTEM to acquire and share AK. During those interactions, developers can tag the AK they feel necessary to retrieve later (see Figure 3B), supported by the tagging service for Slack or another UTEM, such as email, Trello, Skype (see our past implementation in [18]). ...
Article
Full-text available
Agile global software engineering challenges architectural knowledge (AK) management since face-to-face interactions are preferred over comprehensive documentation, which causes AK loss over time. The AK condensation concept was proposed to reduce AK losing, using the AK shared through unstructured electronic media. A crucial part of this concept is a classification mechanism to ease AK recovery in the future. We developed a Slack complement as a classification mechanism based on social tagging, which recommends tags according to a chat/message topic, using natural language processing (NLP) techniques. We evaluated two tagging modes: NLP-assisted versus alphabetical auto-completion, in terms of correctness and time to select a tag. Fifty-two participants used the complement emulating an agile and global scenario and gave us their complement’s perceptions about usefulness, ease of use, and work integration. Messages tagged through NLP recommendations showed fewer semantic errors, and participants spent less time selecting a tag. They perceived the component as very usable, useful, and easy to be integrated into the daily work. These results indicated that a tag recommendation system is necessary to classify the shared AK accurately and quickly. We will improve the NLP techniques to evaluate AK condensation in a long-term test as future work.
... However, the startup may be driven off course in the process by piling up TD. This delays the advancement of new features, raises difficult quality issues and undermines team morale (Tom et al. 2013). Common complaints from customers concern functional mistakes in mobile applications, slowness in normal use, and unexpected crashing of applications (Khalid et al. 2014). ...
... Startups may transform the TD into an investment in which the payback time never arrives. Tom et al. (2013) call this "debt amnesty," which happens when the feature or product does not succeed. Further, Avgeriou et al. determined that TD is: ...
Preprint
Full-text available
Over the last 20 years, a very large number of startups have been launched, ranging from mobile application and game providers to enormous corporations that have started as tiny startups. Startups are an important topic for research and development. The fundamentals of success are the characteristics of individuals and teams, partner investors, the market, and the speed at which everything evolves. Startup's business environment is fraught with uncertainty, as actors tend to be young and inexperienced, technologies either new or rapidly evolving, and team-combined skills and knowledge either key or fatal. As over 90 per cent of software startups fail, having a capable and reliable team is crucial to survival and success. Many aspects of this topic have been extensively studied, and the results of the study on human capital are particularly important. Regarding human capital abilities, such as knowledge, experience, skills, and other cognitive abilities, this dissertation focuses on design skills and their deployment in startups. Design is widely studied in artistic and industrial contexts, but its application to startup culture and software startups follows its own method prison. In the method prison, old and conventional means are chosen instead of new techniques and demanding design studies. This means that when a software startup considers design as a foundation for creativity and generating better offerings, they can grab any industry with a disruptive agenda, making anything software-intensive.
... In particular, the reconstructed architecture serves as a medium to conduct diverse analyses such as pattern conformance, dependency analysis or quality attribute analysis [4]. These analyses can help identify technical debt -that is extensively discussed in [147,148,149,154,157] and more particularly architectural technical debt (ATD). ATD is very hard to identify [90]. ...
Preprint
Full-text available
Architectural reconstruction is a reverse engineering activity aiming at recovering the missing decisions on a system. It can help identify the components, within a legacy software application, according to the application's architectural pattern. It is useful to identify architectural technical debt. We are interested in identifying layers within a layered application since the layered pattern is one of the most used patterns to structure large systems. Earlier component reconstruction work focusing on that pattern relied on generic component identification criteria, such as cohesion and coupling. Recent work has identified architectural-pattern specific criteria to identify components within that pattern. However, the architectural-pattern specific criteria that the layered pattern embodies are loosely defined. In this paper, we present a first systematic literature review (SLR) of the literature aiming at inventorying such criteria for layers within legacy applications and grouping them under four principles that embody the fundamental design principles underlying the architectural pattern. We identify six such criteria in the form of design rules. We also perform a second systematic literature review to synthesize the literature on software architecture reconstruction in the light of these criteria. We report those principles, the rules they encompass, their representation, and their usage in software architecture reconstruction .
... Such code requires more significant mental effort to process and understand before a programmer can reliably modify it. Consequently, the programmer's morale and productivity decline as they spend more time and energy reading old code (Tom et al., 2013), increasing the overall cost of development (Sharma & Spinellis, 2018). Researchers (Sharma & Spinellis, 2018;Hozano et al., 2018) and software industry leaders (Fowler, 2018;Martin, 2009) note that such solutions suffer from code smells -properties of the code that might harm its readability and understandability, and as a consequence, the related software quality attributes. ...
Preprint
div>Code smells are structures in code that indicate the presence of maintainability issues. A significant problem with code smells is their ambiguity. They are challenging to define, and software engineers have a different understanding of what a code smell is and which code suffers from code smells. A solution to this problem could be an AI digital assistant that understands code smells and can detect (and perhaps resolve) them. However, it is challenging to develop such an assistant as there are few usable datasets of code smells on which to train and evaluate it. Furthermore, the existing datasets suffer from issues that mostly arise from an unsystematic approach used for their construction. Through this work, we address this issue by developing a procedure for the systematic manual annotation of code smells. We use this procedure to build a dataset of code smells. During this process, we refine the procedure and identify recommendations and pitfalls for its use. The primary contribution is the proposed annotation model and procedure and the annotators’ experience report. The dataset and supporting tool are secondary contributions of our study. Notably, our dataset includes open-source projects written in the C# programming language, while almost all manually annotated datasets contain projects written in Java.</div
... Most software engineering compromises influence the accumulated "debt," which needs to be paid at some point in time to assure long-term project sustainability [7]. Facing TD is becoming even more of an urgent need for many software startups [21,5]. Such startups are known to accumulate TD during their transition from the early phase to the growth phase. ...
Chapter
Context: Pivot has been a common strategical tactic of startups by shifting course of actions to adapt to environmental changes to the companies. Among many factors influencing the decisions of pivot or preserve, technical characteristics of the product and its evolution are possible triggering factors. We have learned that technical debt is an inherent phenomenon in startups that hinders later growth. However, we do not yet know how technical debt might lead to pivoting in startups and what TD processes we observe in different pivoting scenarios. Aim: Our goal is to evaluate how technical debt influences pivoting in growth-phase startups. Methodology: We conducted an empirical study on 11 software startups in Norway and Brazil and analyzed qualitative data using thematic analysis. Results: We identified three ways that technical debt influences pivoting: (1) direct, (2) indirect, and (3) no-influence. Managing and avoiding technical debt significantly reduces the likelihood of technology pivoting and restrains indirect effects on other pivoting types. Contribution: Our study will enable practitioners to address the influence of technical debt on pivoting in growth-phase software startups. Future researchers can benefit from our findings by conducting exploratory studies and providing educated recommendations.
... Researchers began investigating TD in the early 2000s. Until 2010, only a few articles were published, while from 2010 to 2015, the first larger studies emerged, which contributed to conceptualizing TD. 5,6 TD has been categorized. 7 However, only some types of TD have been thoroughly investigated, leaving others in need of more in-depth exploration. ...
Article
Full-text available
Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt (TD) metaphor has gained significant traction as a way to understand and communicate such issues. Almost 25 years after the term was coined in 1992 by Ward Cunningham, and more than 10 years after the first edition of the TechDebt workshop/conference series, we take a brief look at the past, present, and future of TD.
... The authors identified the principal benefit of including GL in literature reviews as the capability of providing useful industry viewpoints and evidence of the quality that cannot always be gathered from peerreviewed literature [25]. Rigorous MLRs have recently been conducted in the field of SE to investigate, for instance, the need for automation for software testing [26], software test maturity assessment and test process improvement [27], security in DevOps [28], the benefits of the adoption of the Scaled Agile framework [29], requirements engineering in software startups [30], technical debt [31], and the financial aspects of its management [32]. ...
Article
Full-text available
The evaluation and assessment of conversational interfaces is a complex task since such software products are challenging to validate through traditional testing approaches. We conducted a systematic Multivocal Literature Review (MLR), on five different literature sources, to provide a view on quality attributes, evaluation frameworks, and evaluation datasets proposed to provide aid to the researchers and practitioners of the field. We came up with a final pool of 118 contributions, including grey (35) and white literature (83). We categorized 123 different quality attributes and metrics under ten different categories and four macro-categories: Relational, Conversational, User-Centered and Quantitative attributes. While Relational and Conversational attributes are most commonly explored by the scientific literature, we testified a predominance of User-Centered Attributes in industrial literature. We also identified five different academic frameworks/tools to automatically compute sets of metrics, and 28 datasets (subdivided into seven different categories based on the type of data contained) that can produce conversations for the evaluation of conversational interfaces. Our analysis of literature highlights that a high number of qualitative and quantitative attributes are available in the literature to evaluate the performance of conversational interfaces. Our categorization can serve as a valid entry point for researchers and practitioners to select the proper functional and non-functional aspects to be evaluated for their products.
... When developing software, it is vitally important to keep the level of technical debt (TD) down since it is well established from several previous studies that TD can, for example, lower development productivity [1], decrease the developers' morale [2] and compromise the overall software quality [3] and even lead to a crisis point when a huge, costly refactoring or replacement of the whole software needs to be undertaken [4]. ...
Article
Full-text available
Context : When developing software, it is vitally important to keep the level of technical debt down since, based on several studies, it has been well established that technical debt can lower the development productivity, decrease the developers' morale and compromise the overall quality of the software, among others. However, even if researchers and practitioners working in today's software development industry are quite familiar with the concept of technical debt and its related negative consequences, there has been no empirical research focusing specifically on how software managers actively communicate and manage the need to keep the level of technical debt as low as possible. Objective : This study aims to understand how software companies give incentives to manage technical debt. This is carried out by exploring how companies encourage and reward practitioners for actively keeping the level of technical debt down add whether the companies use any forcing or penalising initiatives when managing technical debt. Method : As a first step, this paper reports the results of both an online survey providing quantitative data from 258 participants and interviews with 32 software practitioners. As a second step, this study sets out to specifically provide a detailed assessment of additional and in-depth analysis of technical debt management strategies based on an encouraging mindset and attitude from both managers and technical roles to understand how, when and by whom such strategies are adopted in practice. Results : Our findings show that having a technical debt management strategy (specially based on encouragement) can significantly impact the amount of technical debt related to the software. Conclusion : The result indicates that there is considerable unfulfilled potential to influence how software practitioners can further limit and reduce technical debt by adopting a strategy based explicitly on an encouraging mindset from managers where they also specifically dedicate time and resources for technical debt remediation activities.
... debt comprises both technical debt and all digital aspects)(Research Paper 6). Furthermore, digital debt breeds increased, partly recurring costs in the future owing to higher maintenance costs, additional effort to exercise digital options, inefficiency costs, and the cost of implementing regulatory requirements(MacCormack & Sturtevant, 2016;Tom et al., 2013;Woodard et al., 2013)(Research Paper 6). These recurring costs can ...
Thesis
The widespread adoption of digital technologies continues to drive the changing environment of pre-digital organizations. Social, mobile, analytics, cloud, IoT technologies, and blockchain platforms increase the amount of available data and enable new business models. Against this background, incumbents must deal with several challenges and respond to emerging opportunities. While customers' expectations of digital offerings are rising, digital technologies are lowering market-entry barriers, leading to intensified competition. This poses a major challenge for incumbent organizations with a traditional, pre-digital business model. However, these organizations are mostly not designed for digital technologies and their implications because of their inherent structures. Therefore, pre-digital organizations striving for new value creation paths must develop the capabilities required to successfully adopt digital technologies. Furthermore, pre-digital organizations must often change existing routines and established structures to drive digital transformation. This study investigates three areas from a generalized view of the digital transformation of pre-digital organizations. First, how can pre-digital organizations adopt digital technologies? Second, how do they implement structures for digital transformation? Third, how do they organize themselves for new value creation paths? This study includes six research papers, two of which can be assigned to each of these three areas. The first paper examined how pre-digital organizations may approach digital platforms and develop a platform strategy. The second paper investigated the adoption of AI-enabled systems and the effects of the techno-organizational context during the experimentation phase. The third paper introduced various approaches to developing digital capabilities regarding speed and applicability. The fourth paper investigated how pre-digital organizations manage multiple concurrent digital transformation initiatives, demonstrating how beneficial interplay management leads to complementary duality in organizational ambidexterity. The fifth and sixth research papers explored the relationship between organizational agility and organizational reliability. Therefore, the papers elaborate on the decoupling strategy and how organizations should manage their digital debt. In summary, this study examined the complexities of managing digital transformation from the perspective of pre-digital organizations, contributing to a better understanding of digital transformation.
... Even for the most competent organizations, building and maintaining high performing software applications with high quality is a challenging and expensive endeavor [55]. Working in fast-paced environments that demand frequent releases across several products and deployment environments often forces developers to compromise high quality standards in favor of meeting deadlines [33]. ...
Article
http://deepblue.lib.umich.edu/bitstream/2027.42/170139/1/ASE2021_DependencyIntelligentRefcatoringfv__Copy_.pdf
... The early empirical investigations used qualitative, interview based, approaches [20], because little was known about the phenomena. Later, this was followed by observational studies, experience reports, and case studies [21,22,23,24]. This early accumulation of knowledge about the TD phenomena paved a road for more structured empirical investigations using surveys. ...
Preprint
Full-text available
The technical debt (TD) metaphor describes actions made during various stages of software development that lead to a more costly future regarding system maintenance and evolution. According to recent studies, on average 25% of development effort is spent, i.e. wasted, on TD caused issues in software development organizations. However, further research is needed to investigate the relations between various software development activities and TD. The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in the IT industry. Second, to contribute towards precise conceptualization of the TD concept through analysis of causes and effects. In order to address the research objective a family of surveys was designed as a part of an international initiative that congregates researchers from 12 countries -- InsighTD. At country level, national teams ran survey replications with industry practitioners from the respective countries. In total 653 valid responses were collected from 6 countries. Regarding the prevalence of the TD concept 22% of practitioners have only theoretical knowledge about it, and 47% have some practical experiences with TD identification or management. Further analysis indicated that senior practitioners who work in larger organizations, larger teams, and on larger systems are more likely to be experienced with TD management. Time pressure or deadline was the single most cited cause of TD. Regarding the effects of TD: delivery delay, low maintainability, and rework were the most cited. InsighTD is the first family of surveys on technical debt in software engineering. It provided a methodological framework that allowed multiple replication teams to conduct research activities and to contribute to a single dataset. Future work will focus on more specific aspects of TD management.
... The early empirical investigations used qualitative, interview based, approaches [20], because little was known about the phenomena. Later, this was followed by observational studies, experience reports, and case studies [21,22,23,24]. This early accumulation of knowledge about the TD phenomena paved a road for more structured empirical investigations using surveys. ...
Article
Full-text available
Context The technical debt (TD) metaphor describes actions made during various stages of software development that lead to a more costly future regarding system maintenance and evolution. According to recent studies, on average 25% of development effort is spent, i.e. wasted, on TD caused issues in software development organizations. However, further research is needed to investigate the relations between various software development activities and TD. Objective The objective of this study is twofold. First, to get empirical insight on the understanding and the use of the TD concept in the IT industry. Second, to contribute towards precise conceptualization of the TD concept through analysis of causes and effects. Method In order to address the research objective a family of surveys was designed as a part of an international initiative that congregates researchers from 12 countries—InsighTD. At country level, national teams ran survey replications with industry practitioners from the respective countries. Results In total 653 valid responses were collected from 6 countries. Regarding the prevalence of the TD concept 22% of practitioners have only theoretical knowledge about it, and 47% have some practical experiences with TD identification or management. Further analysis indicated that senior practitioners who work in larger organizations, larger teams, and on larger systems are more likely to be experienced with TD management. Time pressure or deadlinewas the single most cited cause of TD. Regarding the effects of TD: delivery delay, low maintainability, and rework were the most cited. Conclusion InsighTD is the first family of surveys on technical debt in software engineering. It provided a methodological framework that allowed multiple replication teams to conduct research activities and to contribute to a single dataset. Future work will focus on more specific aspects of TD management.
... Several works in the literature have discussed the management of TD at different levels (e.g., architecture, design, code, test, social, documentation and technology) [13,16,21]. In this regard, several quality or DIs have also been proposed, which are briefly described below. ...
... A simple approach is to check references to low quality in commit messages and correlated them with CCP ( Figs. 2 and 3). The specific terms checked were direct references to "low quality", and related terms like "code smell" (Fowler et al., 1997;Van Emden & Moonen, 2002;Yamashita & Moonen, 2012;Khomh et al., 2009;Taba et al., 2013) and "technical debt" (Cunningham, 1992;Tom et al., 2013;Kruchten et al., 2012). In addition, swearing is also a common way to express dissatisfaction, with more than 200 thousand occurrences compared to only hundreds or thousands for the technical terms. ...
Article
Full-text available
The effort invested in software development should ideally be devoted to the implementation of new features. But some of the effort is invariably also invested in corrective maintenance, that is in fixing bugs. Not much is known about what fraction of software development work is devoted to bug fixing, and what factors affect this fraction. We suggest the Corrective Commit Probability (CCP), which measures the probability that a commit reflects corrective maintenance, as an estimate of the relative effort invested in fixing bugs. We identify corrective commits by applying a linguistic model to the commit messages, achieving an accuracy of 93%, higher than any previously reported model. We compute the CCP of all large active GitHub projects (7,557 projects with 200+ commits in 2019). This leads to the creation of an investment scale, suggesting that the bottom 10% of projects spend less than 6% of their total effort on bug fixing, while the top 10% of projects spend at least 39% of their effort on bug fixing — more than 6 times more. Being a process metric, CCP is conditionally independent of source code metrics, enabling their evaluation and investigation. Analysis of project attributes shows that lower CCP (that is, lower relative investment in bug fixing) is associated with smaller files, lower coupling, use of languages like JavaScript and C# as opposed to PHP and C++, fewer code smells, lower project age, better perceived quality, fewer developers, lower developer churn, better onboarding, and better productivity.
... Also, a tertiary study of a set of 12 MLRs was published in 2019 [16]. According to our lightweight search, and to the best of our knowledge, the first MLR in SE was a MLR on technical debt, published in 2013 [17]. We can see in Figure 2 that, since 2018, there has been an increasing trend. ...
Article
Full-text available
In parallel to academic (peer-reviewed) literature (e.g., journal and conference papers), an enormous extent of grey literature (GL) has accumulated since the inception of software engineering (SE). GL is often defined as “literature that is not formally published in sources such as books or journal articles”, e.g., in the form of trade magazines, online blog-posts, technical reports, and online videos such as tutorial and presentation videos. GL is typically produced by SE practitioners. We have observed that researchers are increasingly using and benefitting from the knowledge available within GL. Related to the notion of GL is the notion of Multivocal Literature Reviews (MLRs) in SE, i.e., a MLR is a form of a Systematic Literature Review (SLR) which includes knowledge and/or evidence from the GL in addition to the peer-reviewed literature. MLRs are useful for both researchers and practitioners because they provide summaries of both the state-of-the-art and -practice in a given area. MLRs are popular in other fields and have started to appear in SE community. It is timely then for a Special Issue (SI) focusing on GL and MLRs in SE. From the pool of 13 submitted papers, and after following a rigorous peer review process, seven papers were accepted for this SI. In this introduction we provide a brief overview of GL and MLRs in SE, and then a brief summary of the seven papers published in this SI.
... Tom et al. [7] performed a multivocal literature review, supplemented by interviews with software practitioners and academics, in order to establish the boundaries of the TD phenomenon. The search process is performed in Google's Web Search engine. ...
Conference Paper
Despite the attention that Technical Debt has attracted over the last years, the quantification of TD Interest still remains rather vague (and abstract). TD Interest quantification is hindered by various factors that introduce a lot of uncertainty, such as: identifying the parts of the system that will be maintained , quantifying the load of maintenance, as well as the size of the maintenance penalty, due to the existence of TD. In this study, we aim to shed light on the current approaches for quantifying TD Interest by exploring existing literature within the TD and Maintenance communities. To achieve this goal, we performed a systematic mapping study on Scopus and explored: (a) the existing approaches for quantifying TD Interest; (b) the existing approaches for estimating Maintenance Cost; and (c) the factors that must be taken into account for their quantification. The broad search process has returned more than 1,000 articles, out of which only 25 provide well-defined mathematical formulas / equations for the quantification of TD Interest or Maintenance Cost (only 6 of them are explicitly for TD Interest). The results suggest that despite their similarities, the quantification of TD Interest presents additional challenges compared to Maintenance Cost Estimation, constituting (at least for the time being) the accurate quantification of TD Interest an open and distant to solve research problem. Regarding the factors that need to be considered for such an endeavor, based on the literature: size, complexity, and business parameters are those that are more actively associated to TD Interest quantification.
... Similarly, there is research for identifying tech debt in test automation and applying software design principles for test automation development. [75][76][77] The criteria for when and what to automate are decided by the factors eligibility, priority, cost, coverage, end user usage, quality, maintainability, and time. [78][79][80] Certainly, there are various impediments for automation, and the factors contributing to hindrance of a robust test automation suite are discussed in Reference 81. ...
Article
Full-text available
Software industry has adopted automated testing widely. The most common method adopted is graphical user interface test automation for the functional scenarios to reduce manual testing and increase the repeatability. Reducing execution time and redundancy to achieve quality “go/no go decisions” provides rational for the executive management to allocate funds to adopt automation and invest in the setup including people, process, and tools to achieve faster time to market. There are a variety of practices engaged by testers, like frameworks, tools, methods, procedures, models, and technologies to achieve automation. Nonetheless, the actual effectiveness in terms of return on investment (ROI) is not known, though there are various formulas to calculate ROI of test automation. The factors that determine the ROI are maturity of test automation, purpose, or intent, picking right tests for automation, knowledge of the tester to derive test coverage, domain expertise, defining right metrics like defects found by automation runs, cost versus reduction of time, labor versus quality of scripts, repeatability, and results. These factors form the base of the questions designed for the survey. The paper presents a survey and analysis to understand the ROI of test automation from industry test professionals from both product and services organizations.
... The phrase 'Technical debt' was first introduced in 1992 by Ward Cunningham [24]. Existing literature defines TD as an implementation construct that is profitable in short term but problematic for future work and changes [6], [10], [40], [72], [73]. Alves et al. devised a TD taxonomy with some new types i.e. people, process, service, usability debts [7]. ...
Preprint
Full-text available
Technical debt (TD) is a metaphor for code-related problems that arise as a result of prioritizing speedy delivery over perfect code. Given that the reduction of TDs can have long-term positive impact in the software engineering life-cycle (SDLC), TDs are studied extensively in the literature. However, very few of the existing research focused on the technical debts of R programming language despite its popularity and usage. Recent research by Codabux et al. [21] finds that R packages can have 10 diverse TD types analyzing peer-review documentation. However, the findings are based on the manual analysis of a small sample of R package review comments. In this paper, we develop a suite of Machine Learning (ML) classifiers to detect the 10 TDs automatically. The best performing classifier is based on the deep ML model BERT, which achieves F1-scores of 0.71 - 0.91. We then apply the trained BERT models on all available peer-review issue comments from two platforms, rOpenSci and BioConductor (13.5K review comments coming from a total of 1297 R packages). We conduct an empirical study on the prevalence and evolution of 10 TDs in the two R platforms. We discovered documentation debt is the most prevalent among all types of TD, and it is also expanding rapidly. We also find that R packages of generic platform (i.e. rOpenSci) are more prone to TD compared to domain-specific platform (i.e. BioConductor). Our empirical study findings can guide future improvements opportunities in R package documentation. Our ML models can be used to automatically monitor the prevalence and evolution of TDs in R package documentation.
... The organisational effects of the technological incapacitation phase constrained the digital options of Qiangsheng in two ways. First, the diminished capacity of IT investments, coupled with the accrual of technical debt that have to be repaid with a premium at some point (Tom, Aurum, & Vidgen, 2013), meant that many of Qiangsheng's potential digital options would have been rendered unactionable. The unactionable digital options of Qiangsheng stem from the fact that even if there was an opportunity for IT capability investment "that has been examined and found to be both desirable and feasible" (Sandberg et al., 2014, p. 447), Qiangsheng would still be unable to pursue them in a timely and effective manner. ...
Article
Full-text available
One of the key competitive advantages of sharing economy platforms stems from their superior IT capabilities, which enable operations that are more efficient and/or effective than the incumbent firms. However, given that many of the incumbents tend to be established market leaders or resource‐rich multi‐nationals, their general inability to acquire the appropriate digital options (ie, the IT capabilities that enable the launch of, and response to, competitive actions) to meet the challenge of the sharing economy platforms is puzzling. This study explores this phenomenon by posing the research question: How do the “forces at work” associated with the sharing economy paradigm impact the digital options of incumbent firms? Based on the case of Qiangsheng Taxi and how its IT capabilities have been affected by the emergence of ridesharing platforms, the evidence uncovered suggests that the sharing economy can influence the digital options of incumbent firms through a process of digital attrition, which may be induced by a blend of unfavorable contextual influences (ie, an unbalanced regulatory regime, evolving market preferences and the resourcing advantages of sharing economy platforms). A framework is inductively derived from the data collected that depicts digital attrition as a process of three phases: (a) deinstitutionalization, (b) technological incapacitation, and (c) competitive erosion. In doing so, our study suggests that digital attrition may culminate in IT‐induced competitive disadvantages for incumbent firms, which in turn, could exacerbate the unfavorable contextual influences to complete a vicious cycle that reinforces the negative influence of the sharing economy even further.
... Code that is hard to understand and modify harms the software's maintainability, evolvability, and reliability (Sharma and Spinellis, 2018), introducing technical debt. On the other hand, clean code is easy to understand and maintain, imposing minor cognitive strain on the programmer (Fowler, 2018), thereby increasing their productivity and reducing the chance of introducing bugs (Tom et al., 2013). Such code is a prerequisite for sustainable software development. ...
... This SI shows how there is the potential to increase or take away 'users' agency throughout the technological development process. Decisions made at all stages of technology development embed 'cultural debt'-a play on words related to 'technical debt' or the cost to alter a technology to reach an ideal state of functionality from the present position (Tom et al., 2013). Previous research has already identified the need to move past the adoption heuristic of linear and topdown technology transfer (akin to trickle down technology featuring 'innovators' through 'laggards'; Bronson, 2018Bronson, , 2019Cowie et al., 2020;Eastwood et al., 2021;Fleming et al., 2021;Klerkx & Rose, 2020;Regan, 2019;Rose & Chilvers, 2018). ...
Article
Full-text available
This editorial introduces a special issue (SI) concerning quests for responsible digital agri‐food innovation. We present our interpretations of the concepts of responsible innovation and digital agri‐food innovation and show why they can and have been productively interrelated with social science theories and methods. First, each of the articles in this SI is briefly introduced and synthesised around three themes: (1) the need for a critique of digital ‘solutionism’ in current interdisciplinary research, development and innovation settings; (2) that social science contributes value via the ideas it brings to life to challenge dominant power dynamics and (3) that social scientific imagination and practice is a valuable long‐term investment to both mitigate risk but also embrace socioenvironmental opportunities as we face ongoing sustainability crises into the future. Second, we identify future research considerations arising within the field, sitting at the intersection of social science and agricultural sociotechnical transitions. Our insights relate to challenges and opportunities to ‘do’ social science within the context of contemporary and nascent transitions such as increasing digitalisation. Researchers trained in social science theory and practice can make distinctive contributions to agri‐food innovation processes by making social stakes visible and by advancing inclusive processes of research policy and technology design.
... Regardless of the reason behind sub-optimal code, it can unknowingly (or knowingly [4]) be integrated into the codebase of software systems. The accumulation of sub-optimal code without proper remediation or prevention may lead to large maintenance costs [28] and technical debt [31]. ...
Preprint
Full-text available
Background: Sub-optimal code is prevalent in software systems. Developers may write low-quality code due to many reasons, such as lack of technical knowledge, lack of experience, time pressure, management decisions, and even unhappiness. Once sub-optimal code is unknowingly (or knowingly) integrated into the codebase of software systems, its accumulation may lead to large maintenance costs and technical debt. Stack Overflow is a popular website for programmers to ask questions and share their code snippets. The crowdsourced and collaborative nature of Stack Overflow has created a large source of programming knowledge that can be leveraged to assist developers in their day-to-day activities. Objective: In this paper, we present an exploratory study to evaluate the usefulness of recommending code improvements based on Stack Overflow answers' edits. Method: We propose Matcha, a code recommendation tool that leverages Stack Overflow code snippets with version history and code clone search techniques to identify sub-optimal code in software projects and suggest their optimised version. By using SOTorrent and GitHub datasets, we will quali-quantitatively investigate the usefulness of recommendations given by \textsc{Matcha} to developers using manual categorisation of the recommendations and acceptance of pull-requests to open-source projects.
... Technical debt, studied in [169] for classical software systems, has recently been reviewed in MLBSS in order to identify the specic patterns [14,88,155,167]. Additional to typical technical debt at code level, the machine learningbased systems represent extra tradeos to be overcome for practical practices for the long term development, deployment and maintenance at the system level. ...
Preprint
Full-text available
The rapid development of Machine Learning (ML) has demonstrated superior performance in many areas, such as computer vision, video and speech recognition. It has now been increasingly leveraged in software systems to automate the core tasks. However, how to securely develop the machine learning-based modern software systems (MLBSS) remains a big challenge, for which the insufficient consideration will largely limit its application in safety-critical domains. One concern is that the present MLBSS development tends to be rush, and the latent vulnerabilities and privacy issues exposed to external users and attackers will be largely neglected and hard to be identified. Additionally, machine learning-based software systems exhibit different liabilities towards novel vulnerabilities at different development stages from requirement analysis to system maintenance, due to its inherent limitations from the model and data and the external adversary capabilities. In this work, we consider that security for machine learning-based software systems may arise by inherent system defects or external adversarial attacks, and the secure development practices should be taken throughout the whole lifecycle. While machine learning has become a new threat domain for existing software engineering practices, there is no such review work covering the topic. Overall, we present a holistic review regarding the security for MLBSS, which covers a systematic understanding from a structure review of three distinct aspects in terms of security threats. Moreover, it provides a thorough state-of-the-practice for MLBSS secure development. Finally, we summarise the literature for system security assurance, and motivate the future research directions with open challenges. We anticipate this work provides sufficient discussion and novel insights to incorporate system security engineering for future exploration.
... He states that TD is "not quite right code" which we postpone making right, and working on not-quite-right code counts as the interest on the debt. Moreover, Tom et al. 3 explored the TD metaphor and outlined the first framework to provide a consolidated understanding of the TD phenomenon and to discuss its positive and negative consequences. Although TD increases productivity and speed in the short term, its long-term impact on software artifacts at different stages of the life cycle, such as additional cost during maintenance, has been observed as more crucial 4,5,6 . ...
Article
Full-text available
Refactoring, which aims to improve the internal structure of the software systems preserving their behavior, is the most common payment strategy for technical debt (TD) by removing the code smells. There exist many studies presenting code smell detection approaches/tools or investigating their impact on quality attributes. There are also studies that focus on refactoring techniques, their relation with quality attributes, tool supports, and opportunities for them. Although there are several studies addressing the gap between refactoring and TD indicators, the empirical evidence provided is still limited. In this study, we examine the distribution of 29 refactoring types among the different projects and their relation with code smells or faults. We explore the refactoring types that are most commonly performed together and other activities performed with refactorings. We conduct a large exploratory study with automatically detected 57,528 refactorings, 37,553 smells, 27,340 faults, and 134,812 commits of 33 Java projects. Results show that some refactoring types are more commonly applied by developers. Our analysis indicates that refactorings usually remove or do not affect the code smells, and this contradicts with the previous studies. Also, the commits in which refactoring(s) is performed are three times more fault inducing than those without refactoring. Refactoring, which aims to improve the internal structure of the software systems preserving their behavior, is the most common payment strategy for TD by removing code smells. In this study, we examine the distribution of 29 refactoring types among the different projects and their relation with codes smells or faults. Results show that some refactoring types are more commonly applied by developers, and refactorings usually remove or do not affect the code smells, and this contradicts the previous studies.
... According to Li et al. (2015a), the management of TD is an important step to achieve good quality in the development and maintenance of the software, since most of the debts are often not managed. By Tom et al. (2013), it is necessary to define processes that can track these technical debts, so that later, decisions can be based on the problem identified. Also, recent research shows that knowing the existence of technical debt influences the behaviour of the team, i.e. applying the best techniques of identification and measurement, for example, can significantly improve software development practices (Tonin, 2018). ...
Preprint
Full-text available
Context: Technical Debt requirements are related to the distance between the ideal value of the specification and the system's actual implementation, which are consequences of strategic decisions for immediate gains, or unintended changes in context. To ensure the evolution of the software, it is necessary to keep it managed. Identification and measurement are the first two stages of the management process; however, they are little explored in academic research in requirements engineering. Objective: We aimed at investigating which evidence helps to strengthen the process of TD requirements management, including identification and measurement. Method: We conducted a Systematic Literature Review through manual and automatic searches considering 7499 studies from 2010 to 2020, and including 61 primary studies. Results: We identified some causes related to Technical Debt requirements, existing strategies to help in the identification and measurement, and metrics to support the measurement stage. Conclusion: Studies on TD requirements are still preliminary, especially on management tools. Yet, not enough attention is given to interpersonal issues, which are difficulties encountered when performing such activities, and therefore also require research. Finally, the provision of metrics to help measure TD is part of this work's contribution, providing insights into the application in the requirements context.
... In 1993, Cunningham introduced a metaphor, technical debt, to describe an ad hoc solution for programming problems (Cunningham 1992). Since this introduction, many researchers have studied technical debt (Brown et al. 2010;Kruchten et al. 2012;Tom et al. 2013). Potdar and Shihab (2014) investigated the technical debt intentionally implemented by a developer and explicitly noted in source code comments. ...
Article
Full-text available
In software development, ad hoc solutions that are intentionally implemented by developers are called self-admitted technical debt (SATD). Because the existence of SATD spreads poor implementations, it is necessary to remove it as soon as possible. Meanwhile, container virtualization has been attracting attention in recent years as a technology to support infrastructure such as servers. Currently, Docker is the de facto standard for container virtualization. In Docker, a file describing how to build a container (Dockerfile) is a set of procedural instructions; thus, it can be considered as a kind of source code. Moreover, because Docker is a relatively new technology, there are few developers who have accumulated good or bad practices for building Docker container. Hence, it is likely that Dockerfiles contain many SATDs, as is the case with general programming language source code analyzed in previous SATD studies. The goal of this paper is to categorize SATDs in Dockerfiles and to share knowledge with developers and researchers. To achieve this goal, we conducted a manual classification for SATDs in Dockerfile. We found that about 3.0% of the comments in Dockerfile are SATD. In addition, we have classified SATDs into five classes and eleven subclasses. Among them, there are some SATDs specific to Docker, such as SATDs for version fixing and for integrity check. The three most common classes of SATD were related to lowering maintainability, testing, and defects.
... Interview and survey studies confirm that developers address TD concretely and try to manage it during software development [17] [19] [32] [42]. Systematic studies present taxonomies that decompose TD into subcategories related to software artifacts such as design, code, and testing [1] [24] and map TD to different development stages such as architectural debt management [2] [31] [43]. ...
Preprint
Full-text available
Technical debt (TD) refers to suboptimal choices during software development that achieve short-term goals at the expense of long-term quality. Although developers often informally discuss TD, the concept has not yet crystalized into a consistently applied label when describing issues in most repositories. We apply machine learning to understand developer insights into TD when discussing tickets in an issue tracker. We generate expert labels that indicate whether discussion of TD occurs in the free text associated with each ticket in a sample of more than 1,900 tickets in the Chromium issue tracker. We then use these labels to train a classifier that estimates labels for the remaining 475,000 tickets. We conclude that discussion of TD appears in about 16% of the tracked Chromium issues. If we can effectively classify TD-related issues, we can focus on what practices could be most useful for their timely resolution.
Article
Full-text available
In recent years, web application frameworks have been widely practised by many developers to increase programming productivity as the framework are more flexible, rapidly built using CRUD operation, MVC-based, secure and most of them are published under an open-source license which will reduce the final cost of development. Although the CRUD automation in the web application framework boosts the development process, there are many important aspects of a web application absent from the CRUD output. Therefore, this multivocal literature review investigates the records management aspects that are required in modern WA and the perceived benefit of integrating the records management aspect into CRUD operation. The study extracted 284 publications from respectable scientific resources and the grey resources literature created by WA development practitioners outside academic mediums. After a detailed review process, only 14 scientific primary studies and 13 grey studies were considered for this review based on defined inclusion and exclusion criteria. The review shows that the most important aspect required in WA is search, role-based access control, retention, appraisal, search, audit trail, digital archiving, sharing, reporting, inactive files management and several other features. This important aspect has been analyzed and characterized according to its function and features. The method and procedure for integrating the specified aspect into CRUD operation are identified and discussed. Integrating and implementing the specified record management features into CRUD operation will boost the WA development productivity by producing more features as a standard output with integrated records management functions.
Article
Taxonomies capture knowledge about a particular domain in a succinct manner and establish a common understanding among peers. Researchers use taxonomies to convey information about a particular knowledge area or to support automation tasks, and practitioners use them to enable communication beyond organizational boundaries. Even though this important role of taxonomies in software engineering, their quality is seldom evaluated. Our aim is to identify and define taxonomy quality attributes that provide practical measurements, helping researchers and practitioners to compare taxonomies and choose the one most adequate for the task at hand. We reviewed 324 publications from software engineering and information systems research and synthesized, when provided, the definitions of quality attributes and measurements. We evaluated the usefulness of the measurements on six taxonomies from three domains. We propose the definition of seven quality attributes and suggest internal and external measurements that can be used to assess a taxonomy's quality. For two measurements we provide implementations in Python. We found the measurements useful for deciding which taxonomy is best suited for a particular purpose. While there exist several guidelines for creating taxonomies, there is a lack of actionable criteria to compare taxonomies. In this article, we fill this gap by synthesizing from a wealth of literature seven, non‐overlapping taxonomy quality attributes and corresponding measurements. Future work encompasses their further evaluation of usefulness and empirical validation.
Article
Context Technical Debt (TD) contextualizes the technical decisions on shortcuts and workarounds during software development, positively and negatively influencing software evolution. However, TD still seems to confound with any issue occurring during software development, impacting its proper understanding and management in software projects. Goal To synthesize evidence regarding the conceptualization, characteristics, and management of TD in software projects. Method To undertake a tertiary study to strengthen the knowledge of TD using the principles of Grounded Theory to support qualitative analysis. Results Nineteen secondary studies provide evidence on TD and its management. They provided information regarding the TD's understanding (definitions and characteristics) and management (actions and technologies). Some causes, such as project constraints, technical decisions, and team members, promote different types of TD in software projects. The secondary studies also supported identifying the impacts of TD regarding project management, team members, the organization's business, and internal software quality. Besides helping identify TD challenges, such studies contributed to integrating a conjectured conceptual model of TD that can support future discussions and investigations regarding TD's understanding and management. Conclusions The set of evidence regarding TD's understanding, actions, and technologies to manage TD can aid software practitioners in their software projects. However, it is observable an interpretation overload regarding its definition, inducing to classify any issue occurring during the software development as TD. Therefore, further discussions and investigations still represent essential steps towards consolidating a common perspective on TD and its management.
Preprint
Full-text available
This paper presents a tertiary review of software quality measurement research. To conduct this review, we examined an initial dataset of 7,811 articles and found 75 relevant and high-quality secondary analyses of software quality research. Synthesizing this body of work, we offer an overview of perspectives, measurement approaches, and trends. We identify five distinct perspectives that conceptualize quality as heuristic, as maintainability, as a holistic concept, as structural features of software, and as dependability. We also identify three key challenges. First, we find widespread evidence of validity questions with common measures. Second, we observe the application of machine learning methods without adequate evaluation. Third, we observe the use of aging datasets. Finally, from these observations, we sketch a path toward a theoretical framework that will allow software engineering researchers to systematically confront these weaknesses while remaining grounded in the experiences of developers and the real world in which code is ultimately deployed.
Article
Context Cross-version defect prediction (CVDP) is a practical scenario in which defect prediction models are derived from defect data of historical versions to predict potential defects in the current version. Prior research employed defect data of the latest historical version as the training set using the empirical recommended method, ignoring the concept drift between versions, which undermines the accuracy of CVDP. Objective We customized a Selected Training set and Transfer Learning Framework (ST-TLF) with two objectives: a) to obtain the best training set for the version at hand, proposing an approach to select the training set from the historical data; b) to eliminate the concept drift, designing a transfer strategy for CVDP. Method To evaluate the performance of ST-TLF, we investigated three research problems, covering the generalization of ST-TLF for multiple classifiers, the accuracy of our training set matching methods, and the performance of ST-TLF in CVDP compared against state-of-the-art approaches. Results The results reflect that (a) the eight classifiers we examined are all boosted under our ST-TLF, where SVM improves 49.74% considering MCC, as is similar to others; (b) when performing the best training set matching, the accuracy of the method proposed by us is 82.4%, while the experience recommended method is only 41.2%; (c) comparing the 12 control methods, our ST-TLF (with BayesNet), against the best contrast method P15-NB, improves the average MCC by 18.84%. Conclusions Our framework ST-TLF with various classifiers can work well in CVDP. The training set selection method we proposed can effectively match the best training set for the current version, breaking through the limitation of relying on experience recommendation, which has been ignored in other studies. Also, ST-TLF can efficiently elevate the CVDP performance compared with random forest and 12 control methods.
Article
Self-admitted technical debt (SATD) refers to a specific type of technical debt that is introduced intentionally in the software development and maintenance processes. SATD enables practitioners to take some temporary solutions instead of making comprehensive decisions, which will lead to the high complexity of the software. However, most existing studies relied on manual methods for detecting SATDs. A recent study proposed a method HATD that used a hybrid attention-based method to automatically detect SATDs and it achieved the state-of-the-art performance. However, HATD mainly focused on the locality of the comment instances and lacked of the relationship between long-distance and discontinuous comment instances. To address such an issue, in this work, we propose a novel approach named GGSATD. Specifically, GGSATD first builds the graph for comment instances and then employs the gated graph neural network to iteratively update node representation. The global representation can be obtained by the soft attention mechanism and pooling operation. Experiments on 10 projects show that our GGSATD method obtains promising performance against five baseline methods in both within-project and cross-project scenarios. Extended experiments on seven real-world projects illustrate the effectiveness of our GGSATD method.
Article
The goal of software development is to deliver software products with high quality and free from defects, but resource and time constraints often cause the developers to submit incomplete or temporary patches of codes and further bear the additional burden. Therefore, the investigations on identifying self‐admitted technical debt (SATD) to improve code quality have been conducted in recent years. However, missing syntactic structure information and the imbalance distribution bias shorten the SATD identification performance. Addressing to this issue, we present a graph neural network based SATD identification model (GNNSI) to improve the performance. Specifically, we obtain the structure information of the missing SATD in a compositional way to obtain different feature maps for different comments, and use focal loss to handle the imbalance between SATD and non‐SATD classes in the comments. Then extensive experiments on 10 open source projects are conducted, and the results show that GNNSI outperforms the baselines and can help developers to better predict SATDs.
Article
Context Using feature toggles is a technique to turn a feature either on or off in program code by checking the value of a variable in a conditional statement. This technique is increasingly used by software practitioners to support continuous integration and continuous delivery (CI/CD). However, using feature toggles may increase code complexity, create dead code, and decrease the quality of a codebase. Objective The goal of this research is to aid software practitioners in structuring feature toggles in the codebase by proposing and evaluating a set of heuristics and corresponding complexity, comprehensibility, and maintainability metrics based upon an empirical study of open source repositories. Method We identified 80 GitHub repositories that use feature toggles in their development cycle. We conducted a qualitative analysis using 60 of the 80 repositories to identify heuristics and metrics. Then, we conducted a survey of practitioners of 80 repositories to obtain their feedback that the proposed heuristics can be used to guide the structure of feature toggles and to reduce technical debt. We also conducted a case study of the all 80 repositories to analyze relations between heuristics and metrics. Results From the qualitative analysis, we proposed 7 heuristics to guide structuring feature toggles and identified 12 metrics to support the principles embodied in the heuristics. Our survey result shows that practitioners agree that managing feature toggles is difficult, and using identified heuristics can reduce technical debt. Based on our case study, we find a relationship between the adoption of heuristics and the values of metrics. Conclusions Our results support that practitioners should have self-descriptive feature toggles, use feature toggles sparingly, avoid duplicate code in using feature toggles, and ensure complete removal of a feature toggle.
Article
Technical debt (TD) entails the shortcuts and unsuitable choices made during the development or maintenance of an IT system, which can result in negative consequences such as inefficiency and instability of the IT system. Digitalizing the government has led to the development of numerous IT systems which must be maintained to prevent decay, standstill, additional costs, and a decline in software quality. Previous studies on TD have primarily focused on the private sector, while TD in the public sector has largely been ignored. Therefore, this case study investigated TD management in relation to two IT systems in a Danish agency. Through participant observations and in-situ interviews we studied actual TD behavior, while stakeholder theory combined with a categorization of TD types and activities served as our theoretical lens. Thus, our study (1) identifies the stakeholders influencing an agency's TD management, (2) maps stakeholders' actions, and (3) identifies stakeholders' influence on TD. We found that TD extends beyond the influence of software developers and is also influenced by the behavior of several non-technical stakeholders, e.g., the European Parliament. We offer practical recommendations for TD management based on these findings.
Article
Data science (DS) applications not only suffer from traditional software faults but may also suffer from data‐specific and model‐related faults. Fault models play an important role in evaluating and designing tests for testing DS applications. The existing fault models do not consider DS specific faults. In this study, we built a fault model DS applications. We investigate the faults by using diverse approaches: (i) a multi‐vocal literature survey of published literature, (ii) semi‐structured interviews of industry experts. The Multi‐vocal study allows us to synthesize the existing knowledge from researchers and practitioners. Qualitative data from semi‐structured interviews provide us with insights into the nature of faults encountered by practitioners. We combine the results of (i) and (ii) to derive a detailed fault model. The developed fault model is further validated through a quantitative survey of industry practitioners, and the respondents were asked to identify the faults from our proposed fault model that they have experienced and classify those faults based on their severity as perceived by practitioners and its frequency. The results show that practitioners consider prediction bias and model decay as the most severe faults while data sampling and splitting faults along with feature engineering faults are the most frequent. This study proposes a fault model for testing data science (DS) applications, which was derived from a multi‐vocal literature survey and semi‐structured interviews of industry experts. Industry practitioners further validate the fault model. They identified the faults from the fault model they experienced and classified them based on their severity and frequency. The results show that prediction bias and model decay are the most severe faults, while data sampling and splitting faults and feature engineering faults are the most frequent.
Article
Project-based learning is the most common approach to software engineering education, due to its emphasis on the teamwork skills essential to real-world collaborations. This study developed an automated programming assessment system (APAS) featuring a code-quality evaluation scheme to overcome difficulties in assessing the contribution of individual team members. Team participation is visualized on a weekly basis to provide insights pertaining to team dynamics, and metrics based on code quality allow the segmentation of students by level of contribution. Insights provided by the proposed system were also shown to facilitate interventions aimed at improving code quality. Empirical analysis based on submission data from 146 students (41 teams) demonstrated the feasibility of the proposed system in monitoring group-based learning projects at the university level, particularly in detecting free-riders.
Article
Full-text available
Cloud computing (CC) is the delivery of computing services on demand and is charged using a “pay per you use” policy. Of the multiple services offered by CC, SaaS is the most popular and widely adapted service platform and is used by billions of organizations due to its wide range of benefits. However, security is a key challenge and obstacle in cloud adoption and therefore needs to be addressed. Researchers and practitioners (R&P) have discussed various security challenges for SaaS along with possible solutions. However, no research study exists that systematically accumulates and analyzes the security challenges and solutions. To fill this gap and provide the state-of-the-art (SOTA) picture of SaaS security, this study provides a comprehensive multivocal literature review (MVLR), including SaaS security issues/challenges and best practices for mitigating these security issues. We identified SaaS security issues/challenges and best practices from the formal literature (FL) as well as the grey literature (GL) to evaluate whether R&P is on the same page or if controversies exist. A total of 93 primary studies were identified, of which 58 are from the FL and 35 belong to the GL. The studies are from the last ten years, from 2010 to 2021. The selected studies were evaluated and analyzed to identify the key security issues faced by SaaS computing and to be aware of the best practices suggested by R&P to improve SaaS security. This MVLR will assist SaaS users to identify the many areas in which additional research and development in SaaS security is required. According to our study findings, data breaches/leakage, identity and access management, governance and regulatory compliance/SLA compliance, and malicious insiders are the key security challenges with the maximum frequency of occurrence in both FL and GL. On the other hand, R&P agree that up-to-date security controls/standards, the use of strong encryption techniques, regulatory compliance/SLA compliance, and multifactor authentication are the most important solutions.
Conference Paper
Full-text available
The management of technical debt ultimately requires decision making - about incurring, paying off, or deferring technical debt instances. This position paper discusses several existing approaches to complex decision making, and suggests that exploring their applicability to technical debt decision making would be a worthwhile subject for further research.
Article
Full-text available
This article aims to stimulate discussion about the issue of rigor in conducting reviews of multivocal literatures. Multivocal literatures, which abound in the field of education, are comprised of all accessible writings on a common, often contemporary topic. The exploratory case study method is proposed as a means to engender rigor in reviews of such literatures. It is argued that it is appropriate to apply the concept of rigor to reviews of multivocal literatures and to use the exploratory case study method as a tool for thinking about procedures that could enhance rigor in such reviews. The article draws upon the authors’ experiences in conducting a review of the literature on school-based management to illustrate how the proposed procedures might be employed.
Article
Full-text available
Automated test execution is one of the more popular and available strategies to minimize the cost for software testing, and is also becoming one of the central concepts in modern software development as methods such as test-driven development gain popularity. Published studies on test automation indicate that the maintenance and development of test automation tools commonly encounter problems due to unforeseen issues. To further investigate this, we performed a case study on a telecommunication subsystem to seek factors that contribute to inefficiencies in use, maintenance, and development of the automated testing performed within the scope of responsibility of a software design team. A qualitative evaluation of the findings indicates that the main areas of improvement in this case are in the fields of interaction design and general software design principles, as applied to test execution system development.
Article
Full-text available
Technical debt is a term that has been used to describe the increased cost of changing or maintaining a system due to expedient shortcuts taken during its development. Much of the research on technical debt has focused on decisions made by project architects and individual developers who choose to trade off short-term gain for a longer-term cost. However, in the context of enterprise software development, such a model may be too narrow. We explore the premise that technical debt within the enterprise should be viewed as a tool similar to financial leverage, allowing the organization to incur debt to pursue options that it couldn't otherwise afford. We test this premise by interviewing a set of experienced architects to understand how decisions to acquire technical debt are made within an enterprise, and to what extent the acquisition of technical debt provides leverage. We find that in many cases, the decision to acquire technical debt is not made by technical architects, but rather by non-technical stakeholders who cause the project to acquire new technical debt or discover existing technical debt that wasn't previously visible. We conclude with some preliminary observations and recommendations for organizations to better manage technical debt in the presence of some enterprise-scale circumstances.
Article
Full-text available
Many research have focused on new formal methods, integrating formal methods into agile ones, and assessing the agility of formal methods. This paper proves that formal methods can survive in an agile world; they are not obsolete and can be integrated into it. The potential for combining agile and formal methods holds promise. It might not always be an easy partnership, and succeeding will depend on a fruitful interchange of expertise between the two communities. Conducting a realistic trial project using a combined approach with an appropriate formal methods tool in a controlled environment will help assess the effectiveness of such an approach.
Conference Paper
Full-text available
Delivering increasingly complex software-reliant systems demands better ways to manage the long-term effects of short-term expedients. The technical debt metaphor is gaining significant traction in the agile development community as a way to understand and communicate such issues. The idea is that developers sometimes accept compromises in a system in one dimension (e.g., modularity) to meet an urgent demand in some other dimension (e.g., a deadline), and that such compromises incur a "debt": on which "interest" has to be paid and which the "principal" should be repaid at some point for the long-term health of the project. We argue that the software engineering research community has an opportunity to study and improve this concept. We can offer software engineers a foundation for managing such trade-offs based on models of their economic impacts. Therefore, we propose managing technical debt as a part of the future research agenda for the software engineering field.
Conference Paper
Full-text available
Agile developers are generally reluctant to non-agile practices. Promoted by senior software practitioners, agile methods were intended to avoid traditional engineering practices and rather focus on delivering working software as quickly as possible. Thus, the unique measure in Scrum, a well known framework for managing agile projects, is velocity. Its main purpose is to demonstrate the progress in delivering working software. In software engineering (SE), measurement programs have more in depth purposes and allow teams and individuals to improve their development process along with providing better product quality and control over the project. This paper will describe the experience and the approach used in an agile SE company to design and initiate a measurement program taking into account the specificities of their agile environment, principles and values. The lessons learned after five months of investigation are twofold. The first one shows how agile teams, in comparison to traditional teams, have different needs when trying to establish a measurement program. The second confirms that agile teams, as many other groups of workers, are reluctant and resistant to change. Finally, the preliminary results show that agile people are more interested in value delivery, technical debt, and multiple aspects related to team dynamics and will cooperate to the collection of data as soon as there tools can do it for them. It is believed that this research could suggest new guidelines for elaborating specific measurement programs in other agile environments.
Article
Full-text available
Over the past 25 years, we've made great advances in tooling, technologies, and techniques that make software design more concrete. But design still requires careful thought.
Article
Full-text available
Enabling continued, steady change requires that we integrate design corrections and adjustments into the natural course of development.
Article
Full-text available
Our studies indicate that strategic refactoring using design patterns is the most effective way to repair decaying code for object-oriented (OO) systems. However, applying a pattern-based approach to legacy system repair or even post-design pattern injection is often difficult and, in some cases if misapplied, detrimental
Article
Technical debt utilises financial debt as a metaphor to describe the phenomenon of increasing software development costs over time. Whilst this phenomenon is evidently detrimental to the long-term success of software development, it appears to be poorly understood in the academic literature. The absence of a clear definition and model for technical debt means that the notion of technical debt remains metaphorical, thus preventing the realisation of technical debt's utility as a conceptual and technical communication device. This exploratory study reconciles the high-level, abstracted view of technical debt presented in academic literature. It establishes the boundaries of the technical debt phenomenon and develops a comprehensive theoretical framework to facilitate future research. The resulting theoretical framework portrays a holistic view of technical debt that incorporates a set of precedents and outcomes, as well as the phenomenon itself.
Article
As the semiconductor market begins to recover and customers begin to order new products in higher volumes, product competitiveness, and time-to-market will be absolutely critical. This is a good time to take stock of your development readiness and to understanding how well legacy software assets will support the product roadmap.
Article
Technical debt, which results from the tension between engineering best practices and other factors, needs to be managed. Using a simple but slow algorithm in a prototype can be exactly the correct path, as long as you have a plan for how you are going to update the code before it ships. Understanding, communicating, and managing technical debt can make a huge difference in both the short- and long-term success of a system. unintentional and intentional debt need to be distinguished and it is found that when a system is nearing end of life, incurring debt becomes more attractive, since all debt is retired when a system is decommissioned. Another side of Web-based services in particular is that a correct but inefficient solution can cost a company more money, for example, in the form of server-farm rental fees. Fortunately, this makes the debt easy to translate into dollar terms, which nontechnical stakeholders usually find easier to understand than assertions about maintainability.
Article
Shortcuts that save money and time today can cost you down the road.
Article
An interview study involving 35 practitioners from a variety of domains aimed to characterize technical debt at the ground level to find out how software practitioners perceive it. The study also aimed to understand the context in which technical debt occurs, including its causes, symptoms, and effects. In addition, the study focused on how practitioners currently deal with technical debt. This analysis paints a picture of a large, complex balancing act of various short- and long-term concerns. The Web Extra gives the interview questions used by Erin Lim, Nitin Taksande, and Carolyn Seaman.
Article
Technical debt is the technical work developers owe a system, typically caused by speeding up development, e.g. before a software release. Approaches, such as code smell detection, have been developed to identify particular kinds of debt, e.g. design debt. Up until now, code smell detection has been used to help point to components that need to be freed from debt by refactoring. To date, a number of methods have been described for finding code smells in a system. However, typical debt properties, such as the value of the debt and interest rate to be paid, have not been well established. This position paper proposes an approach to using cost/benefit analysis to prioritize technical debt reduction work by ranking the value and interest of design debt caused by god classes. The method is based on metric analysis and software repository mining and is demonstrated on a commercial software application at a mid-size development company. The results are promising: the method helps to identify which refactoring activities should be performed first because they are likely to be cheap to make yet have significant effect, and which refactorings should be postponed due to high cost and low payoff.
Article
Technical debt describes the effect of immature software artifacts on software maintenance - the potential of extra effort required in future as if paying interest for the incurred debt. The uncertainty of interest payment further complicates the problem of what debt should be incurred or repaid and when. To help software managers make informed decisions, a portfolio approach is proposed in this paper. The approach leverages the portfolio management theory in the finance domain to determine the optimal collection of technical debt items that should be incurred or held. We expect this approach could provide a new perspective for technical debt management.
Article
Making a decision about whether to fix or defer fixing a defect is important to software projects. Deferring defects accumulates a technical debt that burdens the software team and customer with a less than optimal solution. The decision to defer fixing a defect is made by Software Change Control Boards (CCBs) based on a set of decision factors. In this paper, we evaluated the set of decision factors used by two CCBs at ABB in the context of technical debt management The aim was to determine how a model of cost and benefits of incurring technical debt could be part of the CCB decision process. We identified the cost categories and decision factors for fixing and deferring defects as a result of interviews with CCB members. We found that the decision factors could incorporate the financial aspects when using the technical debt metaphor. We identify opportunities for further research to integrate technical debt concepts with the decision factors towards better long term outcomes.
Conference Paper
There are a number of conflicting forces between short- and long-term considerations for software release planning in industry. For example, from a business perspective it is usually desired with a short time-to-market. However, from software quality perspective it is usually desired to have a longer time-to-market such that the proper architectural mechanisms can be put in place, which in the long-term reduce development cost and addresses quality aspects. In this paper we outline some of these conflicting forces, with a focus on long-lived systems, and examplify how they impact product quality and time-to-market. In this paper we propose a simple, but useful, extension of the release planning process that addresses these conflicting forces. The method is inspired from empirical data captured in a multiple case study involving 7 companies.
Article
Research on code reviews has often focused on defect counts instead of defect types, which offers an imperfect view of code review benefits. In this paper, we classified the defects of nine industrial (C/C++) and 23 student (Java) code reviews, detecting 388 and 371 defects, respectively. First, we discovered that 75 percent of defects found during the review do not affect the visible functionality of the software. Instead, these defects improved software evolvability by making it easier to understand and modify. Second, we created a defect classification consisting of functional and evolvability defects. The evolvability defect classification is based on the defect types found in this study, but, for the functional defects, we studied and compared existing functional defect classifications. The classification can be useful for assigning code review roles, creating checklists, assessing software evolvability, and building software engineering tools. We conclude that, in addition to functional defects, code reviews find many evolvability defects and, thus, offer additional benefits over execution-based quality assurance methods that cannot detect evolvability defects. We suggest that code reviews may be most valuable for software products with long life cycles as the value of discovering evolvability defects in them is greater than for short life cycle systems.
Conference Paper
The national financial market turmoil that began in 2008 and continues to this day forced Iowa student loan and other student loan providers to make significant changes. This is a story about how Iowa student loan found innovative ways to continue to meet the need for private student loans and how the technical changes needed to accomplish this were implemented with relative ease. Three different periods of time are analyzed from 2007-2009 and conclusions are drawn to determine possible sources of our success. The main conclusions are: ensuring the business and development teams are speaking the same language, writing tests in a way that is easy to understand, having business savvy developers and tech savvy business analysts, paying down technical debt is a necessary and continual aspect of system design, the importance of prioritization, and making undefined requirements as configurable as possible.
Article
Today's software companies face the challenges of highly distributed development projects and constantly changing requirements. This paper proposes the adoption of relevant Free/Libre/Open Source Software (FLOSS) practices in order to improve software development projects in industry. Many FLOSS projects have proven to be very successful, producing high quality products with steady and frequent releases. This study aims to identify FLOSS practices that can be adapted for the corporate environment. To achieve this goal, a framework to compare FLOSS and industrial development methodologies was created. Three successful FLOSS projects were selected as study targets (the Linux Kernel, the FreeBSD operating system, and the JBoss application server), as well as two projects from Ericsson, a large telecommunications company. Based on an analysis of these projects, FLOSS best practices were tailored to fit industrial development environments. The final results consisted of a set of key adoption opportunities that aimed to improve software quality and overall development productivity by importing best practices from the FLOSS environment. The adoption opportunities were then validated at three large corporations.
Article
The AUTOSPEC system is an automatic motor specification software system that primarily serves to non-interactively produce bill of materials from sales orders. At the core, the system applies Expert System and coordinated Relational Database technology ...
Article
The metaphor of technical debt, originally coined by Ward Cunninghamhas helped me recently get a handle on this type of issue. Almost invariably in software projects, developers can be so focused on accomplishing the needed functionality that the software itself grows less understandable, more complex, and harder to modify. Since this system deterioration usually reflects a lack of activity spent in refactoring, documentation, and other aspects of the project infrastructure, we can view it as a kind of debt that developers owe the system. Ward Cunningham's metaphor helps make clear an important trade-off: although a little debt can speed up software development in the short run, this benefit is achieved at the cost of extra work in the future, as if paying interest on the debt. Technical debt gives us a frame work for thinking about the fact that not doing some good things today, no matter how valuable they seem on their own merits, allows us to invest in other good things. In short, there are always trade-offs in life.
Article
The financial crises in Asia have shown the dangers resulting from globalised financial markets without an appropriate international legal and political framework. Effective regulations and supervisory mechanisms are called for. *** DIRECT SUPPORT *** A02GP124 00004
Article
Agile and lean approaches favor self-organizing teams that use low-tech solutions for communicating and negotiating project content and scope in software projects. We consider this approach to have many benefits, but we also recognize that there is information in software projects that does not readily lend itself to low-tech types of visualization. Different characteristics of the code base is one such example. In this paper, we outline metrics functions that can take advantage of more advanced information of the development artifacts and provide the lean or agile team with partially automated decision support for quality assurance actions.
Conference Paper
Some have described Agile and infrastructure as an oxymoron: they just donpsilat fit together. During one year we have focused on using agile techniques in three different infrastructure related projects. From a unique infrastructural point of view, we will show that the term dasiaagile infrastructure' consists of multiple layers. To become effective, each layer needs to be addressed.
Conference Paper
Software release planning is the process of deciding what to include in future release(s) of a product. Basically the problem can be seen as a company-wide optimization problem involving many stakeholders where the goal is to maximize utilization of the often limited resources of a company and turn them into business benefit. Saliu and Ruhe have proposed a set of key aspects for release planning methods, of which only a subset have been validated in industry. In this paper we use the Saliu and Ruhe key aspects as a starting point for identifying key aspects of release planning. To do this we have performed a multiple case study involving 7 international industrial companies, all producers of software intensive products. Our contribution is (1) a more strict meaning of a release planning key aspect, (2) validation of some of the aspects proposed by Saliu and Ruhe, and (3) an extension of the key aspects. We also capture state-of-the-practice for release planning in industry.
Conference Paper
It is widely recognized that a good and appropriate architecture is critical to the success of a software product or system [5]. However, neither the system nor its architecture is static, and a good architecture anticipates and guides the evolution of the system over time. As the system evolves over time, the role of the software architect evolves as well, and skills that enabled an architect to be successful during one phase of a system’s lifetime may not enable success in later phases. This paper proposes a three-phase model to describe the evolution of software systems, and describes the contributions of the software architect which are necessary for success in each phase. This topic is of interest to practicing architects, and to software development managers responsible for selecting and hiring architects to contribute to a software system.
Article
A central feature of the evolution of large software systems is that change-which is necessary to add new functionality, accommodate new hardware, and repair faults-becomes increasingly difficult over time. We approach this phenomenon, which we term code decay, scientifically and statistically. We define code decay and propose a number of measurements (code decay indices) on software and on the organizations that produce it, that serve as symptoms, risk factors, and predictors of decay. Using an unusually rich data set (the fifteen-plus year change history of the millions of lines of software for a telephone switching system), we find mixed, but on the whole persuasive, statistical evidence of code decay, which is corroborated by developers of the code. Suggestive indications that perfective maintenance can retard code decay are also discussed
Paying down your technical debt In: Coding Horror, Available from
  • J Atwood
Atwood, J., 2009. Paying down your technical debt. In: Coding Horror, Available from: http://www.codinghorror.com/blog/2009/02/paying-down-your-technical-debt.html (accessed 24.08.11). (Online).
Design Debt Economics: A Vocabulary for Describing the Causes, Costs and Cures for Software Maintainability Problems
  • J Elm
ELM, J., 2009. Design Debt Economics: A Vocabulary for Describing the Causes, Costs and Cures for Software Maintainability Problems. IBM, Available: http://www.ibm.com/developerworks/rational/library/edge/09/jun09/ designdebteconomics/ (accessed 24.08.11). (Online).
Available from: http://blogs.construx.com/blogs/stevemcc/archive
  • Mcconnell
McConnell, 2007. Technical debt. In: 10x Software Development, Available from: http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx (accessed 28.04.11). (Online).
Reduce Technical Debt Available from: http://www.castsoftware.com/solutions/reduce-technical-debt
  • Cast
Cast, 2011. Reduce Technical Debt, Available from: http://www.castsoftware.com/solutions/reduce-technical-debt (accessed 19.10.11). (Online).
A maturing field on display at OOPSLA
  • M J Lutz
Lutz, M.J., 1993. A maturing field on display at OOPSLA. IEEE Software 10, 113, *A18.
Using agile techniques to pay back technical debt. MSDN Magazine, Available from
  • D Laribee
Laribee, D., 2009. Using agile techniques to pay back technical debt. MSDN Magazine, Available from: http://msdn.microsoft.com/en-us/magazine/ee819135.aspx (accessed 24.08.11). (Online).
Avoid Getting Buried in Technical Debt Available from: http://www.techrepublic.com/blog/programming-and-development/avoid-getting-buried-in-technical-debt
  • C Camden
Camden, C., 2011. Avoid Getting Buried in Technical Debt, Available from: http://www.techrepublic.com/blog/programming-and-development/avoid-getting-buried-in-technical-debt/3849 (accessed 24.08.11).
Paying down your technical debt
  • Atwood
Going Into Design Debt
  • Haack
When to work on technical debt
  • Hilton
Ward Cunningham's debt metaphor isn't a metaphor
  • Myers
Code debt, product market debt, and customer debt
  • Slinker
Types of Technical Debt
  • Fields
Using agile techniques to pay back technical debt
  • Laribee
A maturing field on display at OOPSLA. IEEE Software
  • Lutz
Seven Strategies for Technical Debt
  • Shriver