In this final installment on the Stakeholder Perspective on Technical Debt, we talk through how organizations will benefit from having technology teams engaged in managing issues affecting intrinsic and extrinsic quality.  An expanded definitional framework of technical debt will be proposed along with detail describing why this expanded definition bridges many gaps that exist today.

Quality Collaboration

When prioritizing a product backlog, product owners need to understand the quality implications associated with their decisions. To avoid the accumulation of unintentional technical debt, technology teams must work with product owners to evaluate the impact to overall quality associated with prioritization strategies. When stepping through the backlog there are three high level alternatives for each feature that must be evaluated.

A. Do it right – no debt

B. Do it quick – take shortcuts and accrue debt

C. Do it later – defer functionality and accrue debt

Because Option C has been considered to primarily impact extrinsic quality it falls outside of the current scope of technical debt. This is a gap because we have seen from the examples in the previous article that impacts in one area of quality often have effects elsewhere. In the case of Option C, features are postponed and the desired solution is essentially being “borrowed” upon. The main difference between Options B and C is which part of the organization explicitly borrows and subsequently pays interest. If the development team borrows by taking shortcuts, they pay the bulk of the interest. When features are deferred, end users make most of the interest payments. Either way the organization must service the accrued debt.

In Agile environments, product owners work very closely with technology teams. This is driven by the fourth principle of the Agile Manifesto which says that “Business people and developers must work together daily throughout the project” [4]. When we have development teams focus exclusively on intrinsic quality we leave it to product owners to manage extrinsic quality. It is critical that technology teams form a united front with product owners measuring and managing technical debt. Active participation from technology teams is critical because they will have insights product owners may not. Designers understand the relationship between user experience and adoption, database developers know what to expect if proper validation controls are not present and systems administrators are aware of the risks associated with legacy platforms. This expertise must be leveraged to ensure product owners do not have a blind spot in their perspective on technical debt.

Proposed Definition

In order to align technical debt’s definitional framework to stakeholder objectives, it should transition from what David Garvin describes as a manufacturing view to a value-based view of quality [2]. The value-based view equates quality to what the customer is willing to pay for and encourages everyone to consider trade-offs between cost and quality [5]. Managing these trade-offs is exactly what technical debt is meant to do. To capture this value-based perspective, the definitional framework should be revised to capture all technical gaps that present risk to required levels of quality. Our proposed definition of technical debt reads as follows.

“Technical debt is any gap within the technology infrastructure or its implementation which has a material impact on the required level of quality.”

The “required level” of quality will vary from one environment to the next based on system requirements. An application that has no sensitive data might not require certain controls. The fact that such an application has no access controls would not be considered technical debt as we have defined it. However, if the application has access controls that are not needed but they cost money to maintain, it would qualify as debt. This might occur if the controls decrease productivity or staff is needed to manage password resets, etc. Technical debt represents the cost associated with gaps between an application and its quality requirements.

Technical debt is shown in Figure 6 as the shaded portion of the graph where the application and its requirements do not overlap. This graph shows an application that has more Functionality and less Maintainability than is required. The cost associated with the unnecessary Functionality is technical debt and is represented by the blue shaded area of the graph. Conversely, the yellow shaded area of Figure 6 represents technical debt that exists because of required levels of Maintainability that are not provided by this solution. The green area of the graph shows where quality requirements are supported which is analogous to technical equity.

Figure 6: Radar chart of technical debt

The proposed definition is focused on gaps in quality alignment that are costing the organization money. The cost associated with these gaps is technical debt where the principal amount is the capital required to close the gap and the interest is the associated recurring cost.

Definition Scope

To make technical debt a manageable concept it must have boundaries. The term “technical” debt implies that the issue driving the cost relates to something in the technology infrastructure. If the principal amount of the debt relates to an investment needed in the technical environment it should be considered a technical debt. The interest may be incurred outside of the technical environment but principal must be technology related. An example to consider is what sometimes is referred to as platform experience debt [6]. This type of debt describes the increased cost incurred to recruit and retain employees who have experience with a legacy or niche platform. While the interest on this debt pays for things outside technology (i.e. human resources), the principal amount owed is clearly in the technical environment.

It follows that if the investment needed to pay back the principal would be made outside the technical environment it should not be considered technical debt. Therefore, gaps in supporting processes would not be considered technical debt. Only the technology required to support required processes should be considered debt. For example, the absence of a business continuity plan would not qualify as debt but the technology necessary to support such a plan would once defined. Without a defined process, requirements would not exist and calculating the principal of the debt is not possible. While processes gaps are not themselves debt, they can and often do lead to technical debt. Inadequate application lifecycle management processes is a case in point. Failure to employ proper quality assurance methods or development standards will result in technical debt in the form of decreased code quality.

There are gray areas that will require consideration, however. An example would be supporting documentation. We propose including supporting items in this gray area if they are considered a tangible extension of the technical asset. If a software package were to be purchased from a vendor, one would expect system documentation to be a part of that package. Therefore, gaps in system documentation could be considered debt.

Conclusion

Regardless of how accurate the perception might be, technology departments are viewed as being out of touch with the rest of the business in many organizations. Part of the reason behind this is because technology and business departments have historically viewed the world through different lenses. Unsurprisingly, challenges and potential solutions often appear different from various vantage points. Issues surrounding software quality are no exception. Business and technology professionals alike must understand and react to issues affecting both intrinsic and extrinsic quality. As we discussed previously, software quality components are hopelessly intertwined.

The definitional framework proposed in this paper accounts for this interdependence by describing issues affecting quality with equal emphasis. Tying the definition to required levels of quality creates a value-based view which is well aligned with the stakeholder’s perspective. Enabling stakeholders to evaluate and manage quality related challenges consistently will allow more effective collaboration towards a common goal. This is the first step towards a centralized governance model where controls like credit limits could be established to better align the risk/reward decisions with organizational standards. Coalescing the expertise of business, technology and risk management resources maximizes effectiveness by creating a united front in the battle against technical debt.

References

[1]	Cunningham, W. 1992. The WyCash Portfolio Management System. OOPSLA’ 92 Experience Report.
[2]	Garvin, D. 1984. What Does “Product Quality” Really Mean?. Sloan Management Review, Fall 1984, 25-45.
[3]	ISO. ISO/IEL 9126-1:2001: Software Engineering – Product Quality. Part 1: Quality Model.Geneva, Switzerland: International Organization for Standardization, 2001.
[4]	Agile Manifesto. [cited 2011 March 5]; Available from: //agilemanifesto.org/principles.html
[5]	Kitchenham, B. 1996. Software Quality: The Elusive Target. IEEE Software, January 1996, 12-21.
[6]	Sterling, C. 2010. Managing Software Debt: Building for Inevitable Change. Boston: Addison-Wesley. P. 17.