The Agile Executive

Making Agile Work

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

About these ads

Written by israelgat

October 28, 2010 at 8:40 am

3 Responses

Subscribe to comments with RSS.

  1. I love it! But I do go back-n-forth on item #1 in that I feel CI *enables* collecting TD metrics. …Or, TD metrics collection *requires* Continuous Inspection.

    But that’s splitting hairs.

    Items 2-9 however put into words, succinctly, something I’ve been desperately trying to say myself.

    Thank you!

    Curtis

    November 1, 2010 at 11:31 am

    • Thanks for the kind words, Curtis!

      What would be your good counsel how to crisp bullet #1?

      Many thanks!

      Israel

      israelgat

      November 1, 2010 at 12:02 pm

  2. If it isn’t obvious already I’m a big fan of the work coming out of the Agile Executive.

    I think collecting Technical Debt as a metric is synonymous with Continuous Inspection.

    My own view on #2 is that Continuous Inspection levels the field of developer proficiency, acting as a mentoring tool to ensure consistent code quality regardless of experience level and fostering more of a team environment. It also frees up developers from what amounts to grunt work to focus on solving business problems (the output). I think your bullet is consistent with that but maybe it’s not apparent.

    1. The technical debt metric *is* Continuous Inspection of the code through ultra-rapid feedback to the software process (see Figure 1 below).

    I also see #3 as more of an *augmentation* than a shifting of emphasis. We’re adding the qualitative assessment of the code (TD) to the already existing qualitative assessment of the software (functional testing).

    3. It augments qualitative assessment (software testing) with quantitative measurement of the quality of the *code*.

    Caper Jones tells us quality is like security, it has to be baked into every step of the SDLC and not just one discreet activity. TD fills a big gap in that regard.

    Curtis

    November 3, 2010 at 8:12 am


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 36 other followers

%d bloggers like this: