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.

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.

Release engineering deals with all activities inbetween regular development and actual usage of asoftware product by the end user, i.e., integration, build, testexecution, packaging and delivery of software. Although re-search on this topic goes back for decades, the increasing heterogeneity and variability of software products along withthe recent trend to reduce the release cycle to days or even hoursstarts to question some of the common beliefs and practicesof the field. For example, a project like Mozilla Firefox releasesevery 6 weeks, generating updates for dozens of existing Fire-fox versions on 5 desktop, 2 mobile and 3 mobile desktopplatforms, each of which for more than 80 locales. In this con-text, the International Workshop on Release Engineering(RELENG) aims to provide a highly interactive forum for re-searchers and practitioners to address the challenges of, findsolutions for and share experiences with release engineering, and to build connections between the various communities.

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.

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 team's 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.

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.

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.