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.
Background
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 software development process [1] and the inherent need for refactoring as applications evolve. Cunningham’s description of technical debt remains the most commonly referenced and is defined as follows.
“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).”
This metaphor allows us to leverage our existing understanding of debt mechanics (i.e. principal, interest, compounding, etc.) which provides an excellent tool for describing technology gaps in financial terms. The ability to use business-friendly terms and concepts facilitates communications between IT departments and other stakeholders.
The software development community conceived the concept and has championed its use over the last two decades. This has resulted in a definitional framework heavily focused on factors influencing intrinsic quality. Understandably, pioneers of the concept used technical debt to describe quality issues within their immediate concern and control. However, the lack of focus on quality outside of software development may have impaired the concept’s ability to gain traction with stakeholders in other areas of discipline.
The debt metaphor adds value in describing gaps across the entire technology infrastructure just as well as it does in software development. In order to capture that additional value, technical debt should describe issues affecting quality more broadly. Stakeholders need a more complete picture of the financial impact associated with shortcomings in the technical environment. This would enable more effective governance models by providing a centralized way to inventory and prioritize initiatives based on objective criteria.
The purpose of this paper is to propose a definitional framework that will bridge several gaps that exist today. First, the definition of technical debt we propose will better align to stakeholder concerns. Second, it will account for the fact that compromises made in one area of quality often impact others. Lastly, it will promote better collaboration between product owners and technology teams when managing quality. The goal of this paper is not to provide a complete conceptual model of technical debt. Rather, it is to establish a broad definitional framework upon which a conceptual model could be built.
Stakeholder Perspective
Technology stakeholders are those individuals or groups who are affected by an organization’s technical environment and have a vested interest in its well-being. These stakeholders can be internal such as business executives, technology leaders, risk managers and end users. They can also include external parties such as regulators, shareholders and customers.
One of technical debt’s most compelling features is its ability to improve stakeholder awareness of technology gaps that are costing an organization money. Because stakeholders are the intended recipients of communications regarding technical debt, the messaging should be relevant to their concerns. Generally, stakeholders are concerned if “the right system was built” and whether or not “the system was built right.” Therefore, it matters little whether interest is being paid on a code base in need of refactoring or on missing features that are impacting efficiency.
Managing technology gaps consistently across the organization provides many stakeholder benefits. Consistency allows business executives to allocate resources more effectively by providing a common economic basis to prioritize initiatives. This approach also paves the way for centralized governance mechanisms. Centralized models provide better transparency around operational challenges thereby improving risk management processes. Transparency and effective risk management decreases the risk profile of the firm which encourages external investment and lowers the cost of capital.
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.
