The Stakeholder Perspective – Introduction
The Stakeholder Perspective – Introduction
Join the DZone community and get the full member experience.Join For Free
Take 60 minutes to understand the Power of the Actor Model with "Designing Reactive Systems: The Role Of Actors In Distributed Architecture". Brought to you in partnership with Lightbend.
I recently led a team of technology and risk management professionals in developing a paper for the Second Workshop on Managing Technical Debt. The call for papers is organized by Carnegie Mellon University’s Software Engineering Institute (SEI) in preparation for the Workshop which will be held in Hawaii in May. I proposed that we explore the topic at its most fundamental level by evaluating how the term is defined and how well suited the concept is to bridging the gap between IT and the business. The team accepted the challenge and we set out to make our case. We argued that in order for the concept of technical debt to reach its full potential, it must describe shortcomings in the technical environment that interfere with organizational objectives regardless of where they reside. In order to build on the technical debt concept there must be a solid foundation. We do not feel that such a foundation currently exists and we set out to make the case for a more broadly defined notion of the concept from what we called “The Stakeholder Perspective.”
In this series, we will break down the content of our paper into logical sections discussing how the current definition focuses primarily on the development team’s perspective of quality and why that should change. The Workshop’s program committee features a very distinguished list of thought leaders on the subject of technical debt including Ward Cunningham, Israel Gat, Jim Highsmith, Steve McConnell and others. I would like to point out that our team has a tremendous amount of appreciation for the contributions these individuals have made to the field of software development and project management. However, we feel that the current definition of technical debt under discussion is too fragmented and narrowly focused. To move the concept forward, the interdependent nature of perspectives on quality must be recognized.
The technical debt metaphor was coined by Ward Cunningham in 1992 to provide a basis for describing the implications associated with shortcuts taken during the development process  and the inherent need for refactoring as software applications evolve. This metaphor allows us to leverage our existing understanding of debt mechanics (i.e. principal, interest, compounding, etc.) which provides an excellent tool for thinking about gaps in technology infrastructure and the implications contained therein. The financial nature of the debt metaphor facilitates communications between business and technology teams by using familiar terms and concepts.
The software development community conceived the concept and has championed its use over the last two decades. This has resulted in a very developer-oriented perspective of what technical debt means and how it should be managed. Unfortunately, no official standards organization has adopted the concept and centralized the forces behind its evolution. This has resulted in numerous definitions of what technical debt is and equally divergent perspectives on what effective governance models should look like. This fragmentation and disproportionate focus on development concerns have impaired the concept’s ability to gain traction outside the development community.
The debt metaphor adds value in describing gaps across the entire technology infrastructure in financial terms just as well as it does in software development. In order to capture that additional value, technical debt must include any gap in the technology infrastructure that has a material impact on quality. Stakeholders need a more complete picture of the financial impact associated with shortcomings in the infrastructure as a whole. This would enable more effective governance models by providing a centralized way to inventory and prioritize initiatives based on objective criteria. Without a more comprehensive approach, technical debt will continue to be a niche concept primarily embraced by the software development community. Broad stakeholder awareness and buy-in is necessary for the power of the metaphor to reach its full potential.
Perspectives on Quality
The conventional wisdom on technical debt has emphasized some elements of software quality like design effectiveness while deemphasizing others such as suitability. The most commonly referenced definition of technical debt is the one proposed by Ward Cunningham .
“Technical Debt includes those internal things that you choose not to do now, but which will impede future development if left undone. This includes deferred refactoring.
Technical Debt doesn’t include deferred functionality, except possibly in edge cases where delivered functionality is ‘good enough’ for the customer, but doesn’t satisfy some standard (e.g., a UI element that isn’t fully compliant with some UI standard).”
In an influential paper evaluating different perspectives on quality, David Garvin describes five different lenses through which quality is typically evaluated . The perspective a person embraces is contingent upon how he or she interacts with the product or system. Garvin defines each of these views as follows .
1. Transcendental view – sees quality as something that can be recognized but not defined. In other words, “I’ll know it when I see it.”
2. User view – sees quality as fitness for purpose.
3. Manufacturing view – sees quality as conformance to specifications.
4. Product view – sees quality as tied to inherent characteristics of the product.
5. Value-based view – sees quality as dependent on the amount a customer is willing to pay for it.
The current definition of technical debt takes on a perspective similar to what Garvin describes as the “manufacturing view.” This view emphasizes impacts to quality internal to system development such as specifications compliance, design effectiveness, defect rates and maintenance challenges. It places little focus on the other perspectives of quality that Garvin describes such as the “user view” where fitness for purpose is considered . The manufacturing view evaluates if the system was built right (i.e. intrinsic quality) as opposed to if the right system was built (i.e. extrinsic quality) . Unfortunately, intrinsic quality and extrinsic quality are hopelessly intertwined. They are two sides of the same coin and must be managed accordingly. Gaps in extrinsic quality often influence intrinsic quality and vice versa. This will be explored further in a later section.
While there are multiple frameworks to measure software quality, the ISO/IEC 9126-1 quality model provides a comprehensive and internationally recognized standard. The ISO model describes quality as a structured set of six characteristics: functionality, reliability, usability, efficiency, maintainability, and portability . In order to evaluate a technology gap’s impact on an organization, its effect on all characteristics of the ISO model should be measured. This creates the opportunity to compare alternative strategies and allocate the firm’s precious resources more effectively.
The Project Triangle
Technology projects are typically constrained by at least one of the following factors which influence quality: time, scope or cost. The Project Management Institute (PMI) describes this phenomenon as the theory of Triple Constraints. The PMI uses the Project Management Triangle in the third edition of the PMBOK to illustrate the relationship between these constraints . While the PMI has made changes to how they describe this concept, the original triangle shown in Figure 1, allows us to easily visualize the relationship between time, scope, cost, and quality. Changing any side has effects on the other two sides and the area of the triangle which represents quality.
Technical debt currently describes how compromises to time, scope or cost impact the “manufacturing view” of quality. This represents a development-centric view of the triangle which shows technical debt’s impact only with respect to software design quality. Figure 2 illustrates a typical scenario where the timeline for a project was cut and technical debt had to be leveraged in the software design to maintain the original scope and cost.
Understanding implications to quality influenced by gaps in other areas of the infrastructure requires us to look at the problem in three dimensions as in Figure 3. This view of quality is better aligned to the stakeholder perspective. In this context, a stakeholder refers to anyone who has an interest in the technical environment under consideration. This could include the development team, project managers, business leaders, risk managers, external customers, regulators, etc.
This perspective shown in Figure 3 transcends the existing concept of technical debt. It does so by considering how gaps throughout the technical environment impact quality. Each “slice” of the three dimensional triangle in Figure 3 represents an area of supporting infrastructure or a domain that impacts it. This is not meant to be an exhaustive list as there are many different ways to slice the infrastructure. The takeaway here is that gaps in each of these slices interrelate and impact the overall quality of the system.
In the next article we will propose an expanded definition of technical debt and explore why we feel this perspective adds more value to the organization.
References will be provided in the last article in the series.
Opinions expressed by DZone contributors are their own.