Stephany Bellomo

Measure it? Manage it? Ignore it? software practitioners and technical debt

The technical debt metaphor is widely used to encapsulate numerous software quality problems. The metaphor is attractive to practitioners as it communicates to both technical and nontechnical audiences that if quality problems are not addressed, things may get worse. However, it is unclear whether there are practices that move this metaphor beyond a mere communication mechanism. Existing studies of technical debt have largely focused on code metrics and small surveys of developers. In this paper, we report on our survey of 1,831 participants, primarily software engineers and architects working in long-lived, software-intensive projects from three large organizations, and follow-up interviews of seven software engineers. We analyzed our data using both nonparametric statistics and qualitative text analysis. We found that architectural decisions are the most important source of technical debt. Furthermore, while respondents believe the metaphor is itself important for communication, existing tools are not currently helpful in managing the details. We use our results to motivate a technical debt timeline to focus management and tooling approaches.

Toward Design Decisions to Enable Deployability: Empirical Study of Three Projects Reaching for the Continuous Delivery Holy Grail

There is growing interest in continuous delivery practices to enable rapid and reliable deployment. While practices are important, we suggest architectural design decisions are equally important for projects to achieve goals such continuous integration (CI) build, automated testing and reduced deployment-cycle time. Architectural design decisions that conflict with deploy ability goals can impede the teams ability to achieve the desired state of deployment and may result in substantial technical debt. To explore this assertion, we interviewed three project teams striving to practicing continuous delivery. In this paper, we summarize examples of the deploy ability goals for each project as well as the architectural decisions that they have made to enable deploy ability. We present the deploy ability goals, design decisions, and deploy ability tactics collected and summarize the design tactics derived from the interviews in the form of an initial draft version hierarchical deploy ability tactic tree.

A study of enabling factors for rapid fielding: combined practices to balance speed and stability

Agile projects are showing greater promise in rapid fielding as compared to waterfall projects. However, there is a lack of clarity regarding what really constitutes and contributes to success. We interviewed project teams with incremental development lifecycles, from five government and commercial organizations, to gain a better understanding of success and failure factors for rapid fielding on their projects. A key area we explored involves how Agile projects deal with the pressure to rapidly deliver high-value capability, while maintaining project speed (delivering functionality to the users quickly) and product stability (providing reliable and flexible product architecture). For example, due to schedule pressure we often see a pattern of high initial velocity for weeks or months, followed by a slowing of velocity due to stability issues. Business stakeholders find this to be disruptive as the rate of capability delivery slows while the team addresses stability problems. We found that experienced practitioners, when faced with these challenges, do not apply Agile practices alone. Instead they combine practices - Agile, architecture, or other - in creative ways to respond quickly to unanticipated stability problems. In this paper, we summarize the practices practitioners we interviewed from Agile projects found most valuable and provide an overarching scenario that provides insight into how and why these practices emerge.

The Practice and Future of Release Engineering: A Roundtable with Three Release Engineers

Three release engineers share their perspectives on quality metrics for releases and on continuous deliverys benefits and limitations. They also discuss release-engineering job skills, the required mind-set, the role of education, and cultural change, and they recommend future research areas. The Web extra at http://youtu.be/O3cJQTZXAI8 is an audio recording of Davide Falessi speaking with Guest Editors Bram Adams and Foutse Khomh about release engineering and its value to the software industry.

Got technical debt?: surfacing elusive technical debt in issue trackers

Concretely communicating technical debt and its consequences is of common interest to both researchers and software engineers. In the absence of validated tools and techniques to achieve this goal with repeatable results, developers resort to ad hoc practices. Most commonly they report using issue trackers or their existing backlog management practices to capture and track technical debt. In a manual examination of 1,264 issues from four issue trackers from open source industry and government projects, we identified 109 examples of technical debt. Our study reveals that technical debt and its related concepts have entered the vernacular of developers as they discuss development tasks through issue trackers. Even when issues are not explicitly tagged as technical debt, it is possible to identify technical debt items in these issue trackers using a categorization method we developed. We use our results and data to motivate an improved definition and an approach to explicitly report technical debt in issue trackers.

Elaboration on an integrated architecture and requirement practice: Prototyping with quality attribute focus

This experience report builds on an earlier study in which we interviewed eight project teams that were using iterative incremental lifecycles. In the study, we captured the practices the teams felt contributed to rapid delivery. We identified a mix of Agile and architecture practices that teams apply to rapidly field software and minimize disruption and delay. In this paper, we elaborate one practice from the study, prototyping with quality attribute focus. We compared two experiences in prototyping focused on quality attribute considerations applied on Scrum projects. We observe through interviews that feature development and prototyping practice spans multiple levels: feature development/sprint, release planning, and portfolio planning. We also observe other factors including rapid trade-off analysis, flexible architecture, and adoption of a set of enabling prototyping guidelines. The analysis of the observations sheds light on several aspects of the practice that enable the team to respond quickly and efficiently when prototype feedback suggests architectural change.

7th international workshop on graphical documentation: documenting SOA-based systems

Service-Oriented Architecture (SOA) is a way of designing, developing, deploying, and managing enterprise systems when business needs and technical solutions are closely aligned. SOA-based systems can be so large and complex, so the role of documentation as a means of conveying information about them is very important. Unfortunately, there is currently little concrete guidance available on how to do so effectively. This workshop will explore the current state-of-the-art and state-of-the-practice in documenting SOA-based systems. The goal is to learn from past experience in documenting other software-intensive systems, including the use of graphical documentation techniques relying on the Unified Modeling Language (UML), but taking into account the unique features and challenges inherent in SOA-based systems (e.g., properly documenting issues related to governance). This workshop is the 7th in a series of events exploring graphical documentation in the context of aiding system understanding.

What to Fix? Distinguishing between Design and Non-design Rules in Automated Tools

Design problems, frequently the result of optimizing for delivery speed, are a critical part of long-term software costs. Automatically detecting such design issues is a high priority for software practitioners. Software quality tools promise automatic detection of common software quality rule violations. However, since these tools bundle a number of rules, including rules for code quality, it is hard for users to understand which rules identify design issues in particular. 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 classified 466 software quality rules from three industry tools—CAST, SonarQube, and NDepend. We found that most of these rules were easily labeled as either non-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, to support automatic detection.

Evolutionary Improvements of Cross-Cutting Concerns: Performance in Practice

As industry continues to embrace incremental software development, many projects run into the challenge of incrementally evolving cross-cutting concerns such as performance. To better understand how projects are handling this challenge in practice, we captured experiences from two financial services that made a series of performance improvements over several months. We discovered some commonality in how these projects refine the work, enabling incremental requirements analysis and allocation of work. In this paper, we describe two key aspects of this evolution: refining the concern by breaking it into its constituent parts to drive design tasks and allocating the parts to iterations as the software evolves. Two practices we observed that support this evolution include ratcheting broadened to conceptually describe the refinement approach in dimensions of response to stimuli in a given context and analysis conducted concurrently and loosely coupled from implementation work. This refinement supports ongoing exploration of the problem and solution, and evolutionary development, such as course changes, when new information is acquired.