Over the past few years I had the privilege of carrying out numerous technical debt engagements for Cutter. The typical makeup of these engagements is: A) align the various stakeholders through a one day workshop on technical debt; B) measure the technical debt; C) devise a plan to reduce it; and, D) work with the client to implement the debt reduction plan. The Cutter Consortium case study here describes how we simultaneously addressed the strategic, tactical and operational needs of one of our clients through such engagement.
These days we are starting to break new grounds in technical debt research, analysis and field work by integrating technical debt techniques in the fabric of Cutter’s client companies. Specifically, we make technical debt techniques an integral part of both the software process and the business process. We drive the software process through the measurement of technical debt. Moreover, we enhance the business process in general, and the governance, risk and compliance (GRC) aspects of it in particular, through technical debt metrics.
The overarching objective in making technical debt techniques an integral part of the software process is to enable new forms of agility. Once the quality of the output of a process — any process — can be quantified, the process can be reimplemented in novel ways. The ability to monitor the quality of the output opens the door for the incorporation of new technologies without taking potentially unbounded risks. By quantifying the quality of software through technical debt metrics, cloud computing, smart mobile devices, and social networking applications can be incorporated in the development process. When these elements are put together, software development can be carried out in novel ways such as “on-demand.”
Likewise, the incorporation of technical debt metrics in the business process is all about determining how fast the business could and should be driven. Think about it like driving a car. Driving on ice at 50mph is likely to end with an accident. Driving on ice at 5mph is probably a much faster (and much safer) way to reach the endpoint. The same rules apply to driving the business. Beyond a certain level of technical debt the business must be driven at a slower pace. Once technical debt has been reduced to an acceptable level, the business can be reliably driven at a faster pace.
By making technical debt techniques an integral part of both the software process and the business process, our clients are able to strike the operational equilibrium depicted in Figure 1. Technical debt analysis is performed on the output of the software process (i.e. the code). The analysis is used to adjust the velocity of the Agile team on an on-going basis, and to improve the software process by providing rich input to the bi-weekly retrospectives. The very same analysis, at a different level of granularity, is used as a critical parameter in the business process. The desired outcome – $$, market share, expansion, etc. – is adjusted to reflect what the software process can realistically deliver and what could be accomplished from a business perspective through the output of the process (i.e. the code).
Figure 1: The Equipoise of Technical Debt
The fascinating thing about balancing process, output and outcome is that it elevates technical debt engagements to the strategic level. The technical debt work itself, of course, is mostly code analysis. The thoughtful use of the technical debt analysis downstream (i.e. in the software process) and upstream (i.e. in the business process) enables the striking of a data-driven balance between the various departments of the enterprise such as sales, marketing, IT, development and QA. Moreover, it enables the enterprise to determine and work towards its outbound objectives in a realistic manner.
 For example: mechanical process, chemical process, or pharmacological process.
 Please note that “development on-demand” is different from “software on-demand.” The first is about developing the software. The second is about invoking it.