The Agile Executive

Making Agile Work

Posts Tagged ‘Error Feedback Ratio

SPaMCAST 112 – Israel Gat, Technical Debt

leave a comment »

Click here for my just published interview on Technical Debt. Major themes discussed in the interview are as follows:

  • The nature of technical debt
  • Tactical and strategic effects of technical debt
  • How the technical debt metric enables you to communicate across levels and functions
  • What Toxic Code is and how it is related to Net Present Value
  • The atrocious nature of code with a high Error Feedback Ratio
  • Cyclomatic complexity as a predictor of error-proneness
  • Use of heat maps in reducing technical debt
  • Use of density of technical debt as a risk indicator
  • How and when to use technical debt to ‘stop-the-line’
  • Use of technical debt in governing software

To illuminate various subtle aspects of technical debt, I use the following metaphors in the interview:

  • The rusty automobiles metaphor
  • The universal source of truth metaphor
  • The Russian dolls metaphor
  • The mine field metaphor
  • The weight reduction metaphor
  • The teeth flossing metaphor

Between the themes and the metaphors, the interview combines theory with pragmatic advice for both the technical and the non-technical listener.


Elbow Room for Handling Technical Debt

with 5 comments

It has become something of a pattern recently. Somebody contacts me about software that has become extremely difficult to maintain. Irrespective of the domain in which the software is applied, the situation is usually characterized by an overwhelming amount of technical debt accompanied by an unaccptably high error feedback ratio. Between those “twins”, both customer support and development are thrashing to the extent that development of new functionality has pretty much ceased. “Just” maintaining the software consumes 90-100% of the cycles of the development teams (and >100% of the cycles of the customer support team).

I do not really mind being considered kind of “Software 911” service. What I find fustraing, however, is that I (and other consultants) typically get called too late. The technical debt when we get called is so overwhelming that it is extremely difficult to generate the cycles required for refactoring the code and establishing solid software engineering  practices. The refactoring “medicine” can’t be taken because customer crises leave no time for learning how to refactor nor for carrying out refactoring in a thoughtful manner. Folks trying to refactor the code get interrupted so often to deal with crises that any attempt to establish flow gets in trouble. The elbow room required for systemic refactoring work simply does not exist anymore.

I am not quite certain where the fine line between “Software 911” and “Pathology 911” lies. My hunch is that once >50% of development resources are assigned to maintaining the software on an on-going basis, it is time to get into refactoring big time. If you don’t, sooner or later you are likely to find you can’t afford the software you developed.

Written by israelgat

October 7, 2009 at 6:56 pm

Sign of the Times

leave a comment »

As I learned the hard way, the post Technical Debt on Your Balance Sheet missed an important risk associated with technical debt.

I got an email today advising me as follows:

Debt Con Expert is now following you on Twitter!

The good services provided by Debt Con Expert are debt consolidation loans, help with bad credit situations, how to tips on filing bankruptcy, etc.  As I do not owe a penny to anyone in this solar system, I am inclined to conclude I am being followed as a result of yesterday’s post on technical debt.

Please be prudent with technical debt. In addition to elevating the error feedback ratio of your software to an unacceptable level,  it might also lead to your mail box being flooded with debt consolidation offers.


Written by israelgat

September 30, 2009 at 11:44 pm