Organizing the Technical Debt Landscape

To date, several methods and tools for detecting source code and design anomalies have been developed. While each method focuses on identifying certain classes of source code anomalies that potentially relate to technical debt (TD), the overlaps and gaps among these classes and TD have not been rigorously demonstrated. We propose to construct a seminal technical debt landscape as a way to visualize and organize research on the subjec

Using Automatic Static Analysis to Identify Technical Debt

The technical debt (TD) metaphor describes a tradeoff between short-term and long-term goals in software development. Developers, in such situations, accept compromises in one dimension (e.g. maintainability) to meet an urgent demand in another dimension (e.g. delivering a release on time). Since TD produces interests in terms of time spent to correct the code and accomplish quality goals, accumulation of TD in software systems is dangerous because it could lead to more difficult and expensive maintenance. The research presented in this paper is focused on the usage of automatic static analysis to identify Technical Debt at code level with respect to different quality dimensions. The methodological approach is that of Empirical Software Engineering and both past and current achieved results are presented, focusing on functionality, efficiency and maintainabilit

Software systems engineering: a journey to contemporary agile and beyond, do people matter?

publishedVersio

Software systems engineering: a journey to contemporary agile and beyond, do people matter?

It is fascinating to view the evolution of software systems engineering over the decades. At the first glance, it could be perceived that the various approaches and processes are different. Are they indeed different? This paper will briefly discuss such a journey relating to findings from an empirical study in some organisations in the UK. Some of the issues described in the literature and by practitioners are common across different software system engineering approaches over the time. It can be argued that human-element of software development plays an integral part in the success of software systems development endeavour. After all, software engineering is a human-centric craft. In order to understand such issues, we crossed the discipline to other disciplines in order to adapt theories and principles that will help to better understand and tackle such matter. Other disciplines have well established human related theories and principles that can be useful. From Japanese management philosophies, we have adapted Lean and knowledge management theories. From psychology, we have adapted Emotional Intelligence (EI). With such an interdisciplinary view, some of the issues can be addressed adequately. Which bring the question: is it really the process or the people? The second author will reflect on his experience attending the first SQM conference 25 years ago. The reflection will discuss the evolution of software systems engineering, and what was changed since then, if at all changed

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

Addressing Software-Based, Platform Interoperability Risks in Defense Systems by Using Distressed Debt Financial Strategies: A Technical Debt Mitigation Concept

This concept paper explores an innovative approach to detecting and managing software vulnerabilities in cyber-physical defense systems. Software-based vulnerabilities that hinder or preclude the maintainability and evolvability of combat systems are a pernicious form of technical debt that threaten all cyber-physical systems. The risks associated with technical debt across increasingly interdependent DoD cyber-physical systems will accelerate if left unchecked. Without changes in acquisition and maintenance practices, we can foresee cascading, potentially catastrophic cross-system failures. To illustrate the risk and possible solutions, we focus on the software embedded in combat systems that are subject to ongoing modernization efforts that extend their applicability to evolving operations. Our research revealed that software vulnerabilities in critical combat systems can threaten the reliability and readiness of those systems. These vulnerabilities provide an opportunity for the defense acquisition communities to create a new capability within their organizations, an Acquisition Technical Debt Team (ATDT) to help detect, manage, and mitigate technical debt. We explore risk classification by including interoperability into risk evaluation schemas. We then apply common distressed debt management models to suggest when and how the ATDT might help manage and mitigate technical debt to help rehabilitate an ailing system.Prepared for the Naval Postgraduate School, Monterey, CA 93943.Naval Postgraduate SchoolApproved for public release; distribution is unlimited.Approved for public release; distribution is unlimited

A Domino Effect: Interdependencies among Different Types of Technical Debt

The paper examines the accrual of technical debt, which represents an increasingly pressing concern for many organizations. To advance understanding of how this debt-accumulation process unfolds, an in-depth case study was conducted with a large manufacturing firm for identifying particular types of technical debt and potential interdependencies among them. The findings point to architecture debt being "the root of all evil" at the case company, setting in motion dynamics that led to the development of other types of technical debt. Scholarship should benefit from this nuanced articulation and illustration of interdependencies across the various types of technical debt