A situation that I and various consultants in the Cutter Agile Practice are often exposed to is a pressing need to reduce technical debt. A prospect calls with respect to some software assets that have ceased to perform adequately. What we almost invariably find once we do the Technical Debt Assessment is that over time the client’s codebase got both bloated and spaghetti-like. As a result, the client is struggling with 10M, 20M or 50M lines of tangled code. The combination of size with “spaghetti tangles” renders it hard to effectively adapt the software as in such code even changing/adding a single line of code could require significant integration and regression efforts. The situation is essentially similar to Clausewitz’s quip about war: “Everything in war is simple, but the simplest thing is difficult”.

 

SpaghettiCode_II

Figure 1: Your code, Sir!

(source: http://en.wikipedia.org/wiki/Spaghetti_code)

If you find yourself these days in a high technical debt situation, you are facing two major challenges: A) the classic challenge of technical debt; and, B) the challenge of technical debt in the era of transient competitive advantage.

The classic challenge of technical debt: Your technical debt situation might not be reversible. If you have not been regularly practicing good “hygiene” through on-going refactoring of the code, chances are you will find it next to impossible to meaningfully reduce the technical debt while responding in parallel to the on-going needs of the business. In particular, technical debt these days could be a major impediment to transforming your legacy enterprise software to continuously deployed software. Unless you are able to make this transformation, you might find yourself unable to offer Software as a Service (SaaS) in a manner that enables real benefits both to your customers and to your company.

The challenge of technical debt in the era of transient competitive advantage: Even if your leadership, strategy and resources enable you to reverse a difficult technical debt situation through a monumental one-time effort, you are still facing the all important question of software strategy in an era in which opportunities are short-lived and competitive edge is transient[1]. To be able to move quickly from one transient advantage to another, your software needs to always be highly adaptable. From a business design perspective, you need to be able to afford the on-going investment in keeping your technical debt really low.

There is a subtle catch here for the Agilist: the theoretical underpinnings of Agile, articulated by distinguished scholars like Nonaka and Takeuchi, view knowledge (that is very possibly acquired through the Agile process itself) as the source of sustainable competitive advantage. Under the “umbrella” of sustainability, the investment required for keeping technical debt low can usually be justified in terms of return on investment. Conversely, a strategy that views competitive advantage as transient requires ruthless parsimony that might not be consistent with assigning resources to technical debt reduction. Simply stated, the time horizon might be too short for the investment in technical debt reduction to pay off.

From_Reduction_to_Production-II

Figure 2: From Reduction to Prevention

The operational implications of this catch for your technical debt initiative are illustrated in Figure 2. You have to shift the emphasis (and some of the corresponding resources) from reduction to prevention. By “Prevention” in this context I primarily mean stopping technical debt at the earliest possible time from propagating through your software development and deployment process. To do so, you measure your technical debt with each build, and stop the (metaphorical) development line to fix the code whenever your technical debt exhibits a worrisome variance.

Think about prevention of technical debt as the twin brother of the ‘test early and often’ tenet of Agile. For both testing and technical debt, the economics of taking action upstream are vastly superior to the economics of doing so downstream. Hence, prevention trumps reduction.

———————-

[1] See Professor McGrath’s The End of Competitive Edge: How to Keep Your Strategy Moving as Fast as Your Business for a good discussion of the risks associated with the assumption that existing advantages will persist.

avatar

Israel Gat

Israel Gat is Director of Cutter Consortium's Agile Product & Project Management practice and a Fellow of the Lean Systems Society. He is recognized as the architect of the Agile transformation at BMC Software. Under his leadership, BMC software development increased Scrum users from zero to 1,000 in four years. Dr. Gat's executive career spans top technology companies, including IBM, Microsoft, Digital, and EMC.

Discussion

 Leave a Reply

(required)

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>