The Agile Executive

Making Agile Work

Archive for October 2010

The Nine Transformative Aspects of the Technical Debt Metric

with 3 comments

No, the technical debt metric will not improve your tennis game. However, using it could help you generate time for practicing the game due to its nine transformative aspects:
  1. The technical debt metric enables Continuous Inspection of the code through ultra-rapid feedback to the software process (see Figure 1 below).
  2. It shifts the emphasis in software development from proficiency in the software process to the output of the process.
  3. It changes the playing fields from qualitative assessment to quantitative measurement of the quality of the software.
  4. It is an effective antidote to the relentless function/feature pressure.
  5. It can be used with any software method, not “just” Agile.
  6. It is applicable to any amount of code.
  7. It can be applied at anypoint in time in the software life-cycle.
  8. These seven characteristics of the technical debt metric enable effective governance of the software process.
  9. The above  characteristics of the technical debt metric enable effective governance of the software product portfolio.

Figure 1: Continuous Inspection

Written by israelgat

October 28, 2010 at 8:40 am

Code2Cloud: Bigger than a Disruption in ALM

with 2 comments


Update, October 22, 2010: Watch this excellent demo of Code2Cloud!

Figure 1: A Representation of the Application Lifecycle Management Concepts

VMware’s Code2Cloud announcement a couple of days ago is intriguing. According to this announcement, the whole development infrastructure is delivered as a service with no setup, no hardware or software to manage. The tedious and time consuming task of setting (and as appropriate modifying) the environment within which coding is carried out is done by Code2Cloud, not by the programming/testing team. As pointed out by colleague and friend Michael Cote, Code2Cloud might have the potential to be quite a disruption in Application Lifecycle Management (ALM):

“The software development tool chain has always been tedious to setup and integrate,” said Red Monk analyst Michael Cote. “While cloud-based development promises to make application delivery, deployment, and use easier, I haven’t seen excellent unified application management approaches that take full advantage of cloud. VMware’s SpringSource Code2Cloud is an ambitious step towards moving much of the development management stack into the cloud and hopefully vacuuming up those tedious application management tasks. It’ll be fun to watch this idea evolve as more and more people and applications start taking advantage of cloud computing.”

Important that such a disruption in the ALM space might be, I believe the main significance of the Code2Cloud announcement is in demonstrating so vividly how powerful the Everything as a Service (EaaS) paradigm could be and probably will be. IMHO Code2Cloud is another proof point to the power of the confluence of Agile, Cloud, Mobile and Social. It is a virtuous cycle of unprecedented impact – in technology delivery, in the structure of markets, in society and in the patterns of living we are accustomed to.

© Copyright 2010 Israel Gat

Figure 2: The Virtuous Cycle of Agile, Cloud, Mobile and Social

The Code2Cloud announcement is primarily about the {Agile –> Cloud} link in Figure 2. The {Cloud –> Mobile}, {Mobile –> Social} and {Social –> Agile} are just as powerful. For example, the {Social –> Agile} link, in conjunction with Cloud and Mobile, opens the door for highly efficient Testing as a Service.

Think of the Code2Cloud as a great example of Everything as a Service. Many other examples of such services are forthcoming. The common denominator of all these examples to come is their transformative power. Not in the tactical sense of “transformative”, but in the deep strategic meaning of the word.

Action item: Start a pilot to evaluate Code2Cloud. Expand rapidly if it meets your development needs. Tie at the earliest point in time to your plans for application delivery, deployment and use in the cloud.


Wrestling with governing your software from a lifcycle perspective? Let me know if you would like assistance in implementing a simple yet highly effective software governance framework that can be used by both technical and non-technical members of your staff. Click Services for details and contact information.



Written by israelgat

October 21, 2010 at 7:19 am

How to Use Technical Debt Data in the M&A Process

leave a comment »

As a starting point, please read Implication of Technical Debt Uncertainty for Software Licensing Negotiations. Everything stated there holds for negotiating M&A deals. In particular:

  • You (as the buyer) should insist on conducting a Technical Debt Assessment as part of the due diligence process.
  • You should be able to deduct the monetized technical debt figure from the price of the acquisition.
  • You should be able to quantify the execution risk (as far as software quality is concerned).

An important corollary holds with respect to acquiring a company who is in the business of doing maintenance on an open source project, helping customers deploy it and training them in its use. You can totally eliminate uncertainty about the quality of the open source project without needing to negotiate permission to conduct technical debt assessment. Actually, you will be advised to conduct the assessment of the software prior to approaching the target company. By so doing, you start negotiations from a position of strength, quite possibly having at your disposal (technical debt) data that the company you consider acquiring does not possess.

Action item: Supplement the traditional due diligence process with a technical debt assessment. Use the monetized technical debt figure to assess execution risk and drive the acquisition price down.


Negotiating a major M&A deal? Let me know if you would like assistance in conducting a technical debt assessment and bringing up technical debt issues with the target company. I will help you with negotiating the acquisition price down. Click Services for details and contact information.


Written by israelgat

October 20, 2010 at 5:37 am

Implications of Technical Debt Uncertainty for Software Licensing Negotiations

with 2 comments

A few years ago, my friend Sebastian Hassinger characterized the state of affairs in enterprise software by the following chart a la Christensen:

The key point this charts gets across is that Open Source Software is becoming “good enough”. It has already met or will soon be meeting the minimum requirements of the enterprise customer. By so doing, open source software will steadily gain ground from traditional enterprise software vendors.

Consider this chart from a buyer’s perspective. Functionality (the vertical axis in the chart) can be thought of as value. Whatever the value might be, it is diminished by technical debt in the software as the debt manifests itself as application crashes, degradation of  performance and possible corruption of customer data. Everything else being equal, an application with lower technical debt per line of code is preferable to an application with a higher technical debt per line of code.

Traditional enterprise software vendors do not typically provide the technical debt data for the applications they sell/license. In contrast, a customer can carry out his/her assessment of technical debt straight off the open source code. For example, colleague and friend John Heintz carried out the following technical debt analysis on the Cassandra open source project:

As demonstrated in this chart, any customer can measure the level of technical debt in an open source software he/she considers. For better or worse, there is no uncertainty about the amount of technical debt the customer will need to live with in an open source software. In contrast, a customer will usually need to live with  uncertainty about the level of technical debt in proprietary software.

Uncertainty has economical consequences. For example, testing a product increases its value because it decreases operational uncertainty. The economical value of uncertainty about technical debt is conceptually depicted in the figure below in which value is adjusted in accord with the knowledge or lack thereof of the amount of technical debt. Please note that the following equation holds for the various intersection points on the Enterprise Customer Requirements line: {T3-T2} < {T1-T0}. What this equation means is that under conditions of uncertain technical debt open source software is becoming more attractive than proprietary software faster than it would without taking technical debt uncertainty into account.

Action Item: Before licensing an enterprise application or renewing an existing license, ask the vendor for technical debt data for the application and the plans to reduce the debt. If the vendor refuses to disclose this data or can’t generate it within a reasonable amount of time, ask for the number of open bugs against this application in the vendor’s bug data base. Use either kind of data to drive down the price. Consider  an open source solution (even if it provides less functionality than the proprietary software product) if the vendor you are dealing with refuses to disclose either the technical debt data or the number of open bugs in the enterprise application.


Negotiating a major enterprise software deal? Let me know if you would like assistance in bringing up technical debt issues with the vendor to help with negotiating the price down. Click Services for details and contact information.


Y2K vis-a-vis IT Debt

leave a comment »

Andrew Dailey of MGI Research and Andy Kyte of Gartner Group kindly did some digging for me on the total amount of money that was spent on Y2K. Here is the bottom line from Andy concluding our email thread on the subject of Y2K expenditures:

I have remained comfortable with our estimate of $300B to $600B.

In other words, it will take an effort comparable to the Y2K effort at the turn of the century to ‘pay back’ the current IT Debt.


Considering modernization of your legacy code? Let me know if you would like assistance in monetizing your technical debt, devising plans to reduce it and governing the debt reduction process. Click Services for details.


Written by israelgat

October 18, 2010 at 6:13 am

Fresh Perspectives on Technical Debt

leave a comment »

Update, October 15: The issue has been posted on the Cutter website (Cutter IT Journal subscription privileges required).

Cutter is just about ready to post the October issue of the IT Journal for which I am the guest editor. Print subscribers should receive it by the last week of the month. Jim Highsmith and I will be reflecting on it in our forthcoming seminar on technical debt in the Cutter Summit.

This issue sheds light on three noteworthy aspects of technical debt techniques:

  1. Their pragmatic use as an integral part of Governance, Risk and Compliance (GRC).
  2. Extending the techniques to shed light on various nuances of technical debt that have alluded us so far.
  3. Applying the techniques in new domains such as devops.

Here is the Table of Contents for this exciting issue:

Opening Statement

by Israel Gat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  3

Modernizing the DeLorean System: Comparing Actual and Predicted Results of a Technical Debt Reduction Project

by John Heintz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

The Economics of Technical Debt

by Stephen Chin, Erik Huddleston, Walter Bodwell, and Israel Gat . . . . . . . . . . . . . . . . . 11

Technical Debt: Challenging the Metaphor

by David Rooney . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Manage Project Portfolios More Effectively by Including Software Debt in the Decision Process

by Brent Barton and Chris Sterling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

The Risks of Acceptance Test Debt

by Ken Pugh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Transformation Patterns for Curing the Human Causes of Technical Debt

by Jonathon Michael Golden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  30

Infrastructure Debt: Revisiting the Foundation

by Andrew Shafer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36


Action Item: Apply the techniques recommended in this issue to govern your software assets in an effective manner.


Overwhelmed by a “mountain” of technical debt? Let me know if you would like assistance in devising and carrying out plans to reduce the debt in a biggest-bang-for-the-buck manner. Click Services for details.


A New Chasm is Forming

leave a comment »

Recently I had frustrating experiences with the bureaucracies of two companies: a company who is bringing me in to consult on continuous value delivery and another company who is interested in a seminar on the consumerization of enterprise software. While the two companies could not be more different, good-hearted engagement managers in both companies cautioned me in advance that their bureaucracies would drive me nuts. Based on my experience to date they were not kidding…

It is a striking contrast between the ease with which I can get precious data from my social network anytime I need it versus the unbelievable waste of time answering the very same question in two or three redundant forms used to screen me as a supplier. This contrast leads me to conclude we are witnessing the formation of a new chasm. It is between companies who stick to their old bureaucratic patterns with respect to suppliers versus those that realize that a supplier these days is a “prosumer.” He/she might provide services one day, consume (other) services the other day.

The business opportunity this chasm presents is providing efficient marketplace infrastructures. Anyone who can collect my data once and provide it as needed to multiple companies I interact with as a supplier will be doing me, and countless number of social networking aficionado, a huge service. Time is simply too precious to be wasted typing in the maiden name of my mother multiple times.

The distinguished economist Ronald Coase perceived reduction of transaction costs as the essence of the firm. His thoughts of more than 70 years ago are right on these days. The bar for transaction costs is “fill in the details only once”. Once in this context means “once in your lifetime.”

Recommendation: Examine the  way your company acquires new customers versus the way it brings aboard suppliers. Something is wrong if your company’s procurement folks routinely tell suppliers “we know you have already given this information, but ‘they’ would not accept it from ‘us’ if you don’t fill this extra form as well.” This being the case, you need to rethink your approach to composite value chains.

Written by israelgat

October 13, 2010 at 7:40 am