Archive for October 2010
The Nine Transformative Aspects of the Technical Debt Metric
- The technical debt metric enables Continuous Inspection of the code through ultra-rapid feedback to the software process (see Figure 1 below).
- It shifts the emphasis in software development from proficiency in the software process to the output of the process.
- It changes the playing fields from qualitative assessment to quantitative measurement of the quality of the software.
- It is an effective antidote to the relentless function/feature pressure.
- It can be used with any software method, not “just” Agile.
- It is applicable to any amount of code.
- It can be applied at anypoint in time in the software life-cycle.
- These seven characteristics of the technical debt metric enable effective governance of the software process.
- The above characteristics of the technical debt metric enable effective governance of the software product portfolio.
Figure 1: Continuous Inspection
Code2Cloud: Bigger than a Disruption in ALM
Update, October 22, 2010: Watch this excellent demo of Code2Cloud!
http://en.wikipedia.org/wiki/File:ALM.svg
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.
____________________________________________________________________________________________________
How to Use Technical Debt Data in the M&A Process
http://www.flickr.com/photos/brajeshwar/266749872/
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.
http://www.flickr.com/photos/tantek/254940135/
____________________________________________________________________________________________________
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.
____________________________________________________________________________________________________
Implications of Technical Debt Uncertainty for Software Licensing Negotiations
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
http://www.flickr.com/photos/plural/4279707276/
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.
____________________________________________________________________________________________________
A New Chasm is Forming
http://www.flickr.com/photos/96483949@N00/192144459/
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.
