Robert L. Nord

A Meta-model for Representing Variability in Product Family Development

Effective product family based development depends on exploiting the commonality and variability in customer requirements. The desirability of variability in products is driven by the (manifest and hidden) needs of the various target market segments identified by various organizational units like sales and marketing. These are informed by other critical components of the context in which product families are developed including the technological capabilities, people/human resources available with the organization, the policies and procedures of the organization, and the strategic objective of the organization. Variability Management is seen as the key aspect that differentiates conventional software engineering and software product line engineering [Kruger 02]. Variability in a product family is defined as a measure of how members of a family may differ from each other [WeissLai 99]. Variability is made explicit using variation points. Variation points are places in design artifacts where a specific decision has been narrowed to several options but the option to be chosen for a particular system has been left open [Atkinson 01]. Identification of the points of variability is crucial in proliferating variety from a single product platform. A central component of product family approach is the management of variability. The product family development process involves managing variations among different members of the family by identifying common and variable aspects in the domain under consideration.

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.

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.

Global Analysis: moving from software requirements specification to structural views of the software architecture

Software architecture design approaches typically treat architecture as an abstraction of the implemented system. However, doing so means that the concepts, languages, notations, and tools for architecture are much more closely related to those of detailed design and implementation than to those of software requirements. Thus the gap between requirements and architecture represents a paradigm shift, while that between architecture and detailed design does not. Global Analysis, which is part of the Siemens Four Views architecture design approach, is a set of activities that serves to reduce the magnitude of this gap by guiding the architecture design process, capturing design rationale, and supporting traceability between requirements and architecture. In this paper Global Analysis is re-examined in light of five years of teaching it, reflecting on it, comparing it to other approaches, and examining how it was applied in four new systems. This experience confirms the value of the Global Analysis activities and the importance of capturing its results. In some cases the benefit went beyond that envisioned, and in other cases Global Analysis was not applied as expected. Because the templates that are provided for Global Analysis results have such a strong influence on how the activities were performed, this will be the focus of future changes.

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.

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.

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.