A Longitudinal Study of Identifying and Paying Down Architectural Debt

Architectural debt is a form of technical debt that derives from the gap between the architectural design of the system as it "should be" compared to "as it is". We measured architecture debt in two ways: 1) in terms of system-wide coupling measures, and 2) in terms of the number and severity of architectural flaws. In recent work it was shown that the amount of architectural debt has a huge impact on software maintainability and evolution. Consequently, detecting and reducing the debt is expected to make software more amenable to change. This paper reports on a longitudinal study of a healthcare communications product created by Brightsquid Secure Communications Corp. This start-up company is facing the typical trade-off problem of desiring responsiveness to change requests, but wanting to avoid the ever-increasing effort that the accumulation of quick-and-dirty changes eventually incurs. In the first stage of the study, we analyzed the status of the "before" system, which indicated the impacts of change requests. This initial study motivated a more in-depth analysis of architectural debt. The results of this analysis were used to motivate a comprehensive refactoring of the software system. The third phase of the study was a follow-on architectural debt analysis which quantified the improvements made. Using this quantitative evidence, augmented by qualitative evidence gathered from in-depth interviews with Brightsquid's architects, we present lessons learned about the costs and benefits of paying down architecture debt in practice.Comment: Submitted to ICSE-SEIP 201

An Evaluation of Design Rule Spaces as Risk Containers

It is well understood that software development can be a risky enterprise and industrial projects often overrun budget and schedule. Effective risk management is, therefore, vital for a successful project outcome. Design Rule Spaces (DRSpaces) have been used by other researchers to understand why implemented software is error-prone. This industrial case study evaluates whether such spaces are durable, meaningful, and isolating risk containers. DRSpaces were created from UML class diagrams of architectural design artefacts. In our study, object orientated metrics were calculated from the UML diagrams, and compared to the error-proneness of the DRSpace implementation, to determine whether architectural coupling translated into implementation difficulties. A correlation between architectural coupling and error-proneness of DRSpaces was observed in the case study. Software developers were asked to identify DRSpaces they found difficult to implement, in order to understand which factors, other than architectural coupling, were also important. The qualitative results show agreement between the code areas developers found difficult to implement and the error-prone DRSpaces. However, the results also show that architectural coupling is just one risk factor of many. The case study suggests that architectural DRSpaces can be used to facilitate a targeted risk review prior to implementation and manage risk

What to Fix? Distinguishing between design and non-design rules in automated tools

Technical debt---design shortcuts taken to optimize for delivery speed---is a critical part of long-term software costs. Consequently, automatically detecting technical debt is a high priority for software practitioners. Software quality tool vendors have responded to this need by positioning their tools to detect and manage technical debt. While these tools bundle a number of rules, it is hard for users to understand which rules identify design issues, as opposed to syntactic quality. This is important, since previous studies have revealed the most significant technical debt is related to design issues. Other research has focused on comparing these tools on open source projects, but these comparisons have not looked at whether the rules were relevant to design. We conducted an empirical study using a structured categorization approach, and manually classify 466 software quality rules from three industry tools---CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either not design (55%) or design (19%). The remainder (26%) resulted in disagreements among the labelers. Our results are a first step in formalizing a definition of a design rule, in order to support automatic detection.Comment: Long version of accepted short paper at International Conference on Software Architecture 2017 (Gothenburg, SE

Sustainability Debt: A Metaphor to Support Sustainability Design Decisions

Sustainability, the capacity to endure, is fundamental for the societies on our planet. Despite its increasing recognition in software engineering, it remains difficult to assess the delayed systemic effects of decisions taken in requirements engineering and systems design. To support this difficult task, this paper introduces the concept of sustainability debt. The metaphor helps in the discovery, documentation, and communication of sustainability issues in requirements engineering. We build on the existing metaphor of technical debt and extend it to four other dimensions of sustainability to help think about sustainability-aware software systems engineering. We highlight the meaning of debt in each dimension and the relationships between those dimensions. Finally, we discuss the use of the metaphor and explore how it can help us to design sustainability-aware software intensive systems

Challenges in understanding, measuring, and managing technical debt

Abstract. Technical debt as a concept is vast and somewhat abstract area. The most basic definition of it is that it is analogous to a bank loan, which must be paid back so you don’t get stated bankrupt. Number of activities required to manage the debt are numerous, as 15 different sources of possible debt are identified. Technical debt management activities, possible sources, and outcomes that unpaid debt might bring are documented in this paper’s background section. Results section contains challenges that technical debt management processes are encountering in understanding, measuring, and managing the debt. Even with existing empirical research on technical debt management, research and industry are having hard time in trying to find the right tools and areas to measure to gain meaningful information on numerous types of technical debt. Without the right metrics, the monitoring tools are not able to provide useful information to aid in communication and decision-making. Currently, the tools focus mainly on code smells (code debt) and are not able to measure the most important aspects of the debt, design, and architectural debt. This research suggests future research topics to improve existing knowledge on certain areas such as the previously mentioned ability to meaningfully measure different kinds of debts

Mashup Archeology: A Case Study in the Role of Digital Technology in Cultural Production

Through examining the phenomena of the musical mashup against the backdrop of the contemporary American legal and economic situations, this work explores the complicated role of digital technology in contemporary cultural production and how it helps to constitute an agency of the contemporary digital subject, oriented towards participation and access. This research comes together in four parts, first weaving together against an understanding of the cultural and technical background as well as the legal and social backdrop that helped to birth the mashup, setting the stage for understanding the different powers at play. Secondly, through considering the construction and determination of culture and cultural production through media in the first instance this work puts those backgrounds into a framework of understanding how these different power structures influence culture. Third, through an understanding of how the mashup functions culturally via these power structures it begins to reveal some of the influences and how they have begun to take hold. Finally, I question what it is that these experiences and technical media are doing within this larger framework that is already controlled through aging and outdated legal and economic frameworks, outlining a framework that helps to understand the architectural determination of the mashup within contemporary society and why this phenomena persists despite legal and economic pushback. Through this exploration I argue that these technologies are turning the subject against these legal systems and towards sharing cultures as the experience with digital technology undermines legal stipulations. This work makes new contributions to understanding not only the role of digital technologies in cultural production, but also the role of digital technologies in the formation of the modern digital subject. Blending cybernetic theory, contemporary media studies, cultural studies, and continental philosophy, this work makes headway toward understanding the complexities of the modern cybernetic subject and how technology plays a role in determining the horizon of opportunities

Architectural technical debt identification:The research landscape

Architectural Technical Debt (ATD) regards sub-optimal design decisions that bring short-term benefits to the cost of long-term gradual deterioration of the quality of the architecture of a software system. The identification of ATD strongly influences the technical and economic sustainability of software systems and is attracting growing interest in the scientific community. During the years several approaches for ATD identification have been conceived, each of them addressing ATD from different perspectives and with heterogeneous characteristics. In this paper we apply the systematic mapping study methodology for identifying, classifying, and evaluating the state of the art on ATD identification from the following three perspectives: publication trends, characteristics, and potential for industrial adoption. Specifically, starting from a set of 509 potentially relevant studies, we systematically selected 47 primary studies and analyzed them according to a rigorously-defined classification framework. The analysis of the obtained results supports both researchers and practitioners by providing (i) an assessment of current research trends and gaps in ATD identification, (ii) a solid foundation for understanding existing (and future) research on ATD identification, and (iii) a rigorous evaluation of its potential for industrial adoption

Assessing Smart Contracts Security Technical Debts

Smart contracts are self-enforcing agreements that are employed to exchange assets without the approval of trusted third parties. This feature has encouraged various sectors to make use of smart contracts when transacting. Experience shows that many deployed contracts are vulnerable to exploitation due to their poor design, which allows attackers to steal valuable assets from the involved parties. Therefore, an assessment approach that allows developers to recognise the consequences of deploying vulnerable contracts is needed. In this paper, we propose a debt-aware approach for assessing security design vulnerabilities in smart contracts. Our assessment approach involves two main steps: (i) identification of design vulnerabilities using security analysis techniques and (ii) an estimation of the ramifications of the identified vulnerabilities leveraging the technical debt metaphor, its principal and interest. We use examples of vulnerable contracts to demonstrate the applicability of our approach. The results show that our assessment approach increases the visibility of security design issues. It also allows developers to concentrate on resolving smart contract vulnerabilities through technical debt impact analysis and prioritisation. Developers can use our approach to inform the design of more secure contracts and for reducing unintentional debts caused by a lack of awareness of security issues

On the Temporality of Introducing Code Technical Debt

Code Technical Debt (TD) is intentionally or unintentionally created when developers introduce inefficiencies in the codebase. This can be attributed to various reasons such as heavy work-load, tight delivery schedule, unawareness of good practices, etc. To shed light into the context that leads to technical debt accumulation, in this paper we investigate: (a) the temporality of code technical debt introduction in new methods, i.e., whether the introduction of technical debt is stable across the lifespan of the project, or if its evolution presents spikes; and (b) the relation of technical debt introduction and the development team’s workload in a given period. To answer these questions, we perform a case study on twenty-seven Apache projects, and inspect the number of Technical Debt Items introduced in 6-month sliding temporal windows. The results of the study suggest that: (a) overall, the number of Technical Debt Items introduced through new code is a stable metric, although it presents some spikes; and (b) the number of commits performed is not strongly correlated to the number of introduced Technical Debt Items