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

A reuse-based economic model for software reference architectures

The growing size and complexity of software systems, together with critical time-to-market needs, demand new software engineering approaches for software development. To remain competitive, organizations are challenged to make informed and feasible value-driven design decisions in order to ensure the quality of the systems. However, there is a lack of support for evaluating the economic impact of these decisions with regard to software reference architectures. This damages the communication among architects and management, which can result in poor decisions. This paper aims at opening a path in this direction by presenting a pragmatic preliminary economic model to perform cost-benefit analysis on the adoption of software reference architectures as key asset for optimizing architectural decision-making. A preliminary validation based on a retrospective study showed the ability of the model to support a cost-benefit analysis presented to the management of an IT consulting company.Preprin

An analysis of techniques and methods for technical debt management: a reflection from the architecture perspective

Technical debt is a metaphor referring to the consequences of weak software development. Managing technical debt is necessary in order to keep it under control, and several techniques have been developed with the goal of accomplishing this. However, available techniques have grown disperse and managers lack guidance. This paper covers this gap by providing a systematic mapping of available techniques and methods for technical debt management, covering architectural debt, and identifying existing gaps that prevent to manage technical debt efficiently

A Triple Bottom-line Typology of Technical Debt: Supporting Decision- Making in Cross-Functional Teams

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

Understanding Architecture Erosion: The Practitioners' Perceptive

As software systems evolve, their architecture is meant to adapt accordingly by following the changes in requirements, the environment, and the implementation. However, in practice, the evolving system often deviates from the architecture, causing severe consequences to system maintenance and evolution. This phenomenon of architecture erosion has been studied extensively in research, but not yet been examined from the point of view of developers. In this exploratory study, we look into how developers perceive the notion of architecture erosion, its causes and consequences, as well as tools and practices to identify and control architecture erosion. To this end, we searched through several popular online developer communities for collecting data of discussions related to architecture erosion. Besides, we identified developers involved in these discussions and conducted a survey with 10 participants and held interviews with 4 participants. Our findings show that: (1) developers either focus on the structural manifestation of architecture erosion or on its effect on run-time qualities, maintenance and evolution; (2) alongside technical factors, architecture erosion is caused to a large extent by non-technical factors; (3) despite the lack of dedicated tools for detecting architecture erosion, developers usually identify erosion through a number of symptoms; and (4) there are effective measures that can help to alleviate the impact of architecture erosion.Comment: The 29th IEEE/ACM International Conference on Program Comprehension (ICPC

Apoio a promoção da visibilidade da dívida técnica

Trabalho de Conclusão de Curso (graduação)—Universidade de Brasília, Faculdade UnB Gama, 2018.A Dívida Técnica é uma metáfora que retrata a perda de qualidade no código, sendo utilizada para tomada de decisões durante o desenvolvimento. Essa dívida técnica parece estar mais presente nas metodologias ágeis de desenvolvimento de software devido a ênfase em entrega de funcionalidades, em que a dívida pode acabar prejudicando a produtividade do time a longo prazo, sendo interessante para essas metodologias poderem tomar decisões relacionadas a dívida técnica de modo mais estratégico para beneficiar a organização. Mas para isso é necessário que essa dívida esteja visível para as partes interessadas, sendo que a dívida precisa ser identificada, coletada e comunicada na organização. Este trabalho discute sobre como é possível promover a visibilidade da Dívida Técnica dentro de um contexto de metodologias ágeis de desenvolvimento. Para isso foi identificado que técnicas existem para se identificar, medir e comunicar a dívida, e bem quais métricas existem para se estimar a dívida. Por fim, é proposto um método para promover a visibilidade, que permite a identificação, medição e comunicação da dívida, podendo fornecer os valores estimados em duas métricas diferentes, a de esforço e em valores financeiros.The Technical Debt is a metaphor that portrays the loss of quality in the code, being used for decision making during development. This technical debt seems to be more present in the agile methodologies of software development due to the emphasis on functional delivery, in which the debt can end up harming the team’s productivity in the long term, being interesting for these methodologies to be able to make decisions related to technical debt in a way to benefit the organization. But for this it is necessary for the debt to be visible to the interested parties, being that the debt needs to be identified, estimated and communicated in the organization. This work discusses how it is possible to promote the visibility of the Technical Debt within a context of agile methodologies of development. For this, it was identified what techniques exist to identify, measure and communicate the debt, and well what metrics exist to estimate the debt. Finally, a method is proposed to promote visibility, which allows the identification, measurement and communication of the debt, and can provide the estimated values in two different metrics, effort and financial figures

Analyzing the concept of technical debt in the context of agile software development: A systematic literature review

Technical debt (TD) is a metaphor that is used to communicate the consequences of poor software development practices to non-technical stakeholders. In recent years, it has gained significant attention in agile software development (ASD). The purpose of this study is to analyze and synthesize the state of the art of TD, and its causes, consequences, and management strategies in the context of ASD. Using a systematic literature review (SLR), 38 primary studies, out of 346 studies, were identified and analyzed. We found five research areas of interest related to the literature of TD in ASD. Among those areas, managing TD in ASD received the highest attention, followed by architecture in ASD and its relationship with TD. In addition, eight categories regarding the causes and five categories regarding the consequences of incurring TD in ASD were identified. Focus on quick delivery and architectural and design issues were the most popular causes of incurring TD in ASD. Reduced productivity, system degradation and increased maintenance cost were identified as significant consequences of incurring TD in ASD. Additionally, we found 12 strategies for managing TD in the context of ASD, out of which refactoring and enhancing the visibility of TD were the most significant. The results of this study provide a structured synthesis of TD and its management in the context of ASD as well as potential research areas for further investigation