The Agile Executive

Making Agile Work

Posts Tagged ‘Software Governance

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

Advertisements

Written by israelgat

October 28, 2010 at 8:40 am

What 108M Lines of Code Tell Us

with 16 comments

Results of the first annual report on application quality have just been released by CAST. The company analyzed 108M lines of code in 288 applications from 75 companies in various industries. In addition to the ‘usual suspects’ –  COBOL, C/C++, Java, .NET – CAST included Oracle 4GL and ABAP in the report.

The CAST report is quite important in shedding light on the code itself. As explained in various posts in this blog, this transition from the process to its output is of paramount importance. Proficiency in the software process is a bit allusive. The ‘proof of the pudding’ is in the output of the software process. The ability to measure code quality enables effective governance of the software process. Moreover, Statistical Process Control methods can be applied to samples of technical debt readings. Such application is most helpful in striking a good balance in ‘stopping the line’ – neither too frequently nor too rarely.

According to CAST’s report, the average technical debt per line of code across all application is $2.82.  This figure, depressing that it might be, is reasonably consistent with quick eyeballing of Nemo. The figure is somewhat lower than the average technical debt figure reported recently by Cutter for a sample of the Cassandra code. (The difference is probably attributable to the differences in sample sizes between the two studies). What the data means is that the average business application in the CAST study is saddled with over $1M in technical debt!

An intriguing finding in the CAST report is the impact of size on the quality of COBOL applications.  This finding is demonstrated in Figure 1. It has been quite a while since I last saw such a dramatic demonstration of the correlation between size and quality (again, for COBOL applications in the CAST study).

Source: First Annual CAST Worldwide Application Software Quality Study – 2010

One other intriguing findings in the CAST study is that “application in government sector show poor changeability.” CAST hypothesizes that the poor changeability might be due to higher level of outsourcing in the government sector compared to the private sector. As pointed out by Amy Thorne in a recent comment posted in The Agile Executive, it might also be attributable to the incentive system:

… since external developers often don’t maintain the code they write, they don’t have incentives to write code that is low in technical debt…

Congratulations to Vincent Delaroche, Dr. Bill Curtis, Lev Lesokhin and the rest of the CAST team. We as an industry need more studies like this!

Why Spend a Whole Morning on Technical Debt?

with one comment

In a little over a month Jim Highsmith and I will deliver our joint seminar on technical debt in the Cutter Summit. Here are eight characteristics of the technical debt metric that make it clear why you should spend 3.5 precious hours on the topic:

  1. The technical debt metric shifts the emphasis in software development from proficiency in the software process to the output of the process.
  2. It changes the playing fields from qualitative assessment to quantitative measurement of the quality of the software.
  3. It is an effective antidote to the relentless function/feature pressure.
  4. It can be used with any software method, not “just” Agile.
  5. It is applicable to any amount of code.
  6. It can be applied at any point in time in the software life-cycle.
  7. These six characteristics of the technical debt metric enable effective governance of the software process.
  8. The above  characteristics of the technical debt metric enable effective governance of the software product portfolio.

The eight characteristics in the aggregate amount to technical debt metric as a ‘universal source of truth.’ It is a meaningful metric at any level of your organization and for any department in it. Moreover, it is applicable to any business process that is not yet taking software quality into account.

Jim and I look forward to meeting you at the summit and interacting with you in the technical debt seminar!

Written by israelgat

September 22, 2010 at 7:32 am

From Vivek Kundra to Devops and Compounding Interest: Cutter’s Forthcoming Special Issue on Technical Debt

leave a comment »

Source: http://www.flickr.com/photos/wallyg/152453473/

In a little over a month the Cutter Consortium will publish a special issue of the Cutter IT Journal (CITJ) on Technical Debt. As the guest editor for this issue I had the privilege to set the direction for it and now have early exposure to the latest and greatest in research and field work from the various authors. This short post is intended to share with you some of the more exciting findings you could expect in this issue of the CITJ.

The picture above of the debt clock is a common metaphor that runs through all articles. The various authors are unanimously of the opinion that one must measure his/her technical debt, embed the measurements in the software governance process and relentlessly push hard to reduce technical debt. One can easily extrapolate this common thread to conjecture an initiative by Vivek Kundra to assess technical debt and its ramification at the national level.

Naturally, the specific areas of interest with respect to technical debt vary from one author to another. From the broad spectrum of topics addressed in the journal, I would like to mention two that are quite representative:

  • One of the authors focuses on the difference between the manifestation of technical debt in dev versus its manifestation in devops, reaching the conclusion that the change in context (from dev to devops) makes quite a difference. The author actually doubts that the classical differentiation between “building the right system” and “building the system right” holds in devops.
  • Another author derives formulas for calculating  Recurring Interest and Compounding Interest in technical debt. The author uses these formulas to demonstrate two scenario: Scenario A in which technical debt as % of total product revenue is 12% and Scenario B in which technical debt as % of total product revenue is 280%. The fascinating thing is that this dramatic difference (12% v. 280%) is induced through much smaller variances in the Recurring Interest and the Compounding Interest.

I will blog much more on the subject when the CITJ issue is published in October. In addition, Jim Highsmith and I will discuss the findings of the various authors as part of our joint seminar on the subject in the forthcoming Cutter Summit.

Stay tuned!