Ipek Ozkaya

In Search of a Metric for Managing Architectural Technical Debt

Practices designed to expedite the delivery of stakeholder value can paradoxically lead to unexpected rework costs that ultimately degrade the flow of value over time. This is especially observable when features are developed based on immediate value, while dependencies that may slow down future development efforts are neglected. The technical debt metaphor conceptualizes this tradeoff between short-term and long-term value: taking shortcuts to optimize the delivery of features in the short term incurs debt, analogous to financial debt, that must be paid off later to optimize long-term success. In this paper, we describe taking an architecture-focused and measurement-based approach to develop a metric that assists in strategically managing technical debt. Such an approach can be used to optimize the cost of development over time while continuing to deliver value to the customer. We demonstrate our approach by describing its application to an ongoing system development effort.

Quality-Attribute Based Economic Valuation of Architectural Patterns

Architectural patterns generate value depending on the utility of the quality attributes that can be achieved from the application of those patterns. However, methods to rigorously evaluate the value-added of patterns do not exist. In this position paper, we make the case that architectural patterns carry economic value in the form of real options, providing designers with the right, but not the obligation, to take subsequent design actions in the future in the face of uncertainty. We summarize our observations in evaluating the relative value of patterns using real option valuation models on a model problem. We draw attention to how such economics-informed approaches can provide belter insights for the selection of situated design strategies.

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.

Technical debt: towards a crisper definition report on the 4th international workshop on managing technical debt

As the pace of software delivery increases and technology rapidly changes, organizations seek guidance on how to insure the sustainability of their software development effort. Over the past four years running the workshops on Managing Technical Debt, we have seen increased interest from the software industry to understanding and managing technical debt. A better understanding of the concept of technical debt, and how to approach it, both from a theoretical and a practical perspective is necessary to advance its state of the art and practice. In this paper, we highlight the current confusion in industry on the definition of technical debt, their contributions that have led to a deeper understanding of this concept and the limits of the metaphor, the criteria to discriminate what is technical debt and not, and areas of further investigation.

Analysis and Management of Architectural Dependencies in Iterative Release Planning

Within any incremental development paradigm, there exists a tension between the desire to deliver value to the customer early and the desire to reduce cost by avoiding architectural refactoring in subsequent releases. What is lacking, however, is quantifiable guidance that highlights the potential benefits and risks of choosing one or the other of these alternatives or a blend of both strategies. In this paper, we assert that the ability to quantify architecture quality with measurable criteria provides engineering guidance for iterative release planning. We demonstrate the use of propagation cost as a proxy for architectural health with dependency analysis of design structure and domain mapping matrices as a quantifiable basis for iteration planning.

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.

Towards engineered architecture evolution

Architecture evolution, a key aspect of software evolution, is typically done in an ad hoc manner, guided only by the competence of the architect performing it. This process lacks the rigor of an engineering discipline. In this paper, we argue that architecture evolution must be engineered — based on rational decisions that are supported by formal models and objective analyses. We believe that evolutions of a restricted form — close-ended evolution, where the starting and ending design points are known a priori — are amenable to being engineered. We discuss some of the key challenges in engineering close-ended evolution. We present a conceptual framework in which an architecture evolutionary trajectory is modeled as a sequence of steps, each captured by an operator. The goal of our framework is to support exploration and objective evaluation of different evolutionary trajectories. We conclude with open research questions in developing this framework.

Technical debt at the crossroads of research and practice: report on the fifth international workshop on managing technical debt

Increasingly, software developers and managers use the metaphor of technical debt to communicate key trade-offs related to release and quality issues. We report here on the Fifth International Workshop on Managing Technical Debt, collocated with the Seventh International Symposium on Empirical Software Engineering and Measurement (ESEM 2013). The workshop participants reiterated the usefulness of the metaphor, shared emerging practices used in software development organizations, and emphasized the need for more research and better means for sharing emerging practices and results.

Managing technical debt in software development: report on the 2nd international workshop on managing technical debt, held at ICSE 2011

The technical debt metaphor is gaining significant traction in the software development community as a way to understand and communicate about issues of intrinsic quality, value, and cost. This is a report on a second workshop on managing technical debt, which took place as part of the 33rd International Conference on Software Engineering (ICSE 2011). The goal of this second workshop was to discuss the management of technical debt: to assess current practice in industry and to further refine a research agenda for software engineering in this area.

Representing Requirement Relationships

Capturing structural relationships between requirements is essential for effective visualization. Existing techniques such as UML, SysML, and goaloriented requirement engineering present a relationship focused approach in visualization; however, a commonly shared understanding of requirement-based relationships has not yet emerged. Considerations in structural and visual representation of requirement relationships are discussed in the paper, drawing issues from commercial tools, UML, SysML requirements diagram and goal-oriented requirement engineering. Lessons learned from authors own experience of developing requirement engineering tool support with graph-based techniques are summarized. Suggestions for areas of investigation for practical and better use of requirement relationships via visualization are provided.