Technical Debt: An empirical investigation of its harmfulness and on management strategies in industry

Background: In order to survive in today\u27s fast-growing and ever fast-changing business environment, software companies need to continuously deliver customer value, both from a short- and long-term perspective. However, the consequences of potential long-term and far-reaching negative effects of shortcuts and quick fixes made during the software development lifecycle, described as Technical Debt (TD), can impede the software development process.Objective: The overarching goal of this Ph.D. thesis is twofold. The first goal is to empirically study and understand in what way and to what extent, TD influences today’s software development work, specifically with the intention to provide more quantitative insight into the field. Second, to understand which different initiatives can reduce the negative effects of TD and also which factors are important to consider when implementing such initiatives.Method: To achieve the objectives, a combination of both quantitative and qualitative research methodologies are used, including interviews, surveys, a systematic literature review, a longitudinal study, analysis of documents, correlation analysis, and statistical tests. In seven of the eleven studies included in this Ph.D. thesis, a combination of multiple research methods are used to achieve high validity.Results: We present results showing that software suffering from TD will cause various negative effects on both the software and the developing process. These negative effects are illustrated from a technical, financial, and a developer’s working situational perspective. These studies also identify several initiatives that can be undertaken in order to reduce the negative effects of TD.Conclusion: The results show that software developers report that they waste 23% of their working time due to experiencing TD and that TD required them to perform additional time-consuming work activities. This study also shows that, compared to all types of TD, architectural TD has the greatest negative impact on daily software development work and that TD has negative effects on several different software quality attributes. Further, the results show that TD reduces developer morale. Moreover, the findings show that intentionally introducing TD in startup companies can allow the startups to cut development time, enabling faster feedback and increased revenue, preserve resources, and decrease risk and thereby contribute to beneficial\ua0effects. This study also identifies several initiatives that can be undertaken in order to reduce the negative effects of TD, such as the introduction of a tracking process where the TD items are introduced in an official backlog. The finding also indicates that there is an unfulfilled potential regarding how managers can influence the manner in which software practitioners address TD

Managing Code Debt in Open Source Software Development Projects: A Digital Options Perspective

In this study, we examine the impact of three commonly used digital options on the accumulation of code debt in open source software development (OSSD) projects. Further, we examine the impact of code debt on three measures of OSSD project performance. Specifically, we hypothesize that increased use of defer options and abandon options is negatively related to the accumulation of code debt, while increased use of growth options is positively related to the accumulation of code debt. Further, we hypothesize that while the accumulation of code debt is negatively related to a project’s market success and the engagement of peripheral developers, it is positively related to the engagement of core developers. To test our hypotheses, we plan to collect and analyze project data from a leading OSSD platform. We expect our findings to provide new theoretical perspectives for researchers and actionable insights for software practitioners

The use of incentives to promote Technical Debt management

When developing software, it is vitally important to keep the level of technical debt down since it is well established from several studies that technical debt can, e.g., lower the development productivity, decrease the developers' morale, and compromise the overall quality of the software. 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

Measuring affective states from technical debt: A psychoempirical software engineering experiment

Software engineering is a human activity. Despite this, human aspects are under-represented in technical debt research, perhaps because they are challenging to evaluate. This study's objective was to investigate the relationship between technical debt and affective states (feelings, emotions, and moods) from software practitioners. Forty participants (N = 40) from twelve companies took part in a mixed-methods design, consisting of a repeated-measures (r = 5) experiment (n = 200), a survey employing a questionnaire, and semi-structured interviews. The statistical analysis shows that different design smells negatively or positively impact affective states. From the qualitative data, it is clear that technical debt activates a substantial portion of the emotional spectrum and is psychologically taxing. Further, the practitioner's reactions to technical debt appear to fall in different levels of maturity. We argue that human aspects in technical debt are important factors to consider, as they may result in, e.g., procrastination, apprehension, and burnout.Comment: 48 pages, 11 figures, submitted to Empirical Software Engineerin

Community Smells -- The Sources of Social Debt: A Systematic Literature Review

Context: Social debt describes the accumulation of unforeseen project costs (or potential costs) from sub-optimal software development processes. Community smells are sociotechnical anti-patterns and one source of social debt that impact software teams, development processes, outcomes, and organizations. Objective: To provide an overview of community smells based on published literature, and describe future research. Method: We conducted a systematic literature review (SLR) to identify properties, understand origins and evolution, and describe the emergence of community smells. This SLR explains the impact of community smells on teamwork and team performance. Results: We include 25 studies. Social debt describes the impacts of poor socio-technical decisions on work environments, people, software products, and society. For each of the 30 identified community smells, we provide a description, management approaches, organizational strategies, and mitigation effectiveness. We identify five groups of management approaches: organizational strategies, frameworks, models, tools, and guidelines. We describe 11 properties of community smells. We develop the Community Smell Stages Framework to concisely describe the origin and evolution of community smells. We describe the causes and effects for each community smell. We identify and describe 8 types of causes and 11 types of effects for community smells. Finally, we provide 8 Sankey diagrams that offer insights into threats the community smells pose to teamwork factors and team performance. Conclusion: Community smells explain the influence work conditions have on software developers. The literature is scarce and focuses on a small number of community smells. Thus, community smells still need more research. This review organizes the state of the art about community smells and provides motivation for future research along with educational material.Comment: Accepted for publication in Information and Software Technolog

The Evolution of Sociology of Software Architecture

The dialectical interplay of technology and sociological development goes back to the early days of human development, starting with stone tools and fire, and coming through the scientific and industrial revolutions; but it has never been as intense or as rapid as in the modern information age of software development and accelerating knowledge society (Mansell and Wehn, 1988; and Nico, 1994, p. 1602-1604). Software development causes social change, and social challenges demand software solutions. In turn, software solutions demand software application architecture. Software architecture (“SA”) (Fielding and Taylor, 2000) is a process for “defining a structural solution that meets all the technical and operations requirements...” (Microsoft, 2009, Chapter I). In the SA process, there is neither much emphasis on the sociological requirements of all social stakeholders nor on the society in w hich these stakeholders use, operate, group, manage, transact, dispute, and resolve social conflicts. For problems of society demanding sociological as well as software solutions, this study redefines software application architecture as “the process of defining a structured solution that meets all of the sociological , technical, and operational requirements…” This investigation aims to l ay the groundwork for, evolve, and develop an innovative and novel sub-branch of scientific study we name the “Sociology of Software Architecture” (hereinafter referred to as “SSA”). SSA is an interdisciplinary and comparative study integrating, synthesizing, and combining elements of the disciplines of sociology, sociology of technology, history of technology, sociology of knowledge society, epistemology, science methodology (philosophy of science), and software architecture. Sociology and technology have a strong, dynamic, and dialectical relationship and interplay, especially in software development. This thesis investigates and answers important and relevant questions, evolves and develops new scientific knowledge, proposes solutions, demonstrates and validates its benefits, shares its case studies and experiences, and advocates, promotes, and helps the future and further development of this novel method of science

Understanding, Analysis, and Handling of Software Architecture Erosion

Architecture erosion occurs when a software system's implemented architecture diverges from the intended architecture over time. Studies show erosion impacts development, maintenance, and evolution since it accumulates imperceptibly. Identifying early symptoms like architectural smells enables managing erosion through refactoring. However, research lacks comprehensive understanding of erosion, unclear which symptoms are most common, and lacks detection methods. This thesis establishes an erosion landscape, investigates symptoms, and proposes identification approaches. A mapping study covers erosion definitions, symptoms, causes, and consequences. Key findings: 1) "Architecture erosion" is the most used term, with four perspectives on definitions and respective symptom types. 2) Technical and non-technical reasons contribute to erosion, negatively impacting quality attributes. Practitioners can advocate addressing erosion to prevent failures. 3) Detection and correction approaches are categorized, with consistency and evolution-based approaches commonly mentioned.An empirical study explores practitioner perspectives through communities, surveys, and interviews. Findings reveal associated practices like code review and tools identify symptoms, while collected measures address erosion during implementation. Studying code review comments analyzes erosion in practice. One study reveals architectural violations, duplicate functionality, and cyclic dependencies are most frequent. Symptoms decreased over time, indicating increased stability. Most were addressed after review. A second study explores violation symptoms in four projects, identifying 10 categories. Refactoring and removing code address most violations, while some are disregarded.Machine learning classifiers using pre-trained word embeddings identify violation symptoms from code reviews. Key findings: 1) SVM with word2vec achieved highest performance. 2) fastText embeddings worked well. 3) 200-dimensional embeddings outperformed 100/300-dimensional. 4) Ensemble classifier improved performance. 5) Practitioners found results valuable, confirming potential.An automated recommendation system identifies qualified reviewers for violations using similarity detection on file paths and comments. Experiments show common methods perform well, outperforming a baseline approach. Sampling techniques impact recommendation performance

Towards Usable API Documentation

The learning and usage of an API is supported by documentation. Like source code, API documentation is itself a software product. Several research results show that bad design in API documentation can make the reuse of API features difficult. Indeed, similar to code smells, poorly designed API documentation can also exhibit 'smells'. Such documentation smells can be described as bad documentation styles that do not necessarily produce incorrect documentation but make the documentation difficult to understand and use. This thesis aims to enhance API documentation usability by addressing such documentation smells in three phases. In the first phase, we developed a catalog of five API documentation smells consulting literature on API documentation issues and online developer discussion. We validated their presence in the real world by creating a benchmark of 1K official Java API documentation units and conducting a survey of 21 developers. The developers confirmed that these smells hinder their productivity and called for automatic detection and fixing. In the second phase, we developed machine-learning models to detect the smells using the 1K benchmark, however, they performed poorly when evaluated on larger and more diverse documentation sources. We explored more advanced models; employed re-training and hyperparameter tuning to further improve the performance. Our best-performing model, RoBERTa, achieved F1-scores of 0.71-0.93 in detecting different smells. In the third phase, we first focused on evaluating the feasibility and impact of fixing various smells in the eyes of practitioners. Through a second survey of 30 practitioners, we found that fixing the lazy smell was perceived as the most feasible and impactful. However, there was no universal consensus on whether and how other smells can/should be fixed. Finally, we proposed a two-stage pipeline for fixing lazy documentation, involving additional textual description and documentation-specific code example generation. Our approach utilized a large language model, GPT- 3, to generate enhanced documentation based on non-lazy examples and to produce code examples. The generated code examples were refined iteratively until they were error-free. Our technique demonstrated a high success rate with a significant number of lazy documentation instances being fixed and error-free code examples being generated

System design and the cost of architectural complexity

Thesis (Ph. D.)--Massachusetts Institute of Technology, Engineering Systems Division, 2013.Cataloged from PDF version of thesis.Includes bibliographical references (p. 159-166).Many modern systems are so large that no one truly understands how they work. It is well known in the engineering community that architectural patterns (including hierarchies, modules, and abstraction layers) should be used in design because they play an important role in controlling complexity. These patterns make a system easier to evolve and keep its separate portions within the bounds of human understanding so that distributed teams can operate independently while jointly fashioning a coherent whole. This study set out to measure the link between architectural complexity (the complexity that arises within a system due to a lack or breakdown of hierarchy or modularity) and a variety of costs incurred by a development organization. A study was conducted within a successful software firm. Measures of architectural complexity were taken from eight versions of their product using techniques recently developed by MacCormack, Baldwin, and Rusnak. Significant cost drivers including defect density, developer productivity, and staff turnover were measured as well. The link between cost and complexity was explored using a variety of statistical techniques. Within this research setting, we found that differences in architectural complexity could account for 50% drops in productivity, three-fold increases in defect density, and order-of-magnitude increases in staff turnover. Using the techniques developed in this thesis, it should be possible for firms to estimate the financial cost of their complexity by assigning a monetary value to the decreased productivity, increased defect density, and increased turnover it causes. As a result, it should be possible for firms to more accurately estimate the potential dollar-value of refactoring efforts aimed at improving architecture.by Daniel J. Sturtevant.Ph.D