The Technical Debt Trap at Agile Tour Toronto 2010

After Fowler’s keynotes, this is the best session that I have attended. The main reason is that its speaker, Michael Norton, was very good: sharp, clear, concise, as a speaker should be.

The presentation was focused on the concept of Technical Debt, conceived by Ward Cunningham back in ’92 and touched by Fowler as well in his third part keynote.

Norton’s intents are to clarify what the metaphor means and which is the proper way to use it. The point is that it’s ok to cut corners in the short timeframe to gain an opportunity (for example, for a demo), but things have to be fixed up properly as soon as possible immediately afterwards. The power of the metaphor lies primarily in the concept of debt and the need of repaying it:

  • Every corner that you cut for a specific purpose, for example in terms of code that you know should be done in a different, better way, is debt
  • All the debt adds up very quickly and it slows you down
  • If you don’t fix that code potentially you’ll end up in a situation where development slows down to a halt and the system needs to be rebuilt from scratch

We should always remember, however, that this is just a metaphor and we can’t stretch it beyond its intended use. It’s indeed a way to think about our own work, it doesn’t magically replace our work with its own laws because we are leaving in a delusion. Norton uses the term metaphorphosis for this kind of phenomenon. In Cunnigham words:

  • “[Many] have explained the debt metaphor and confused it with the idea that you could write code poorly with the intention of doing a good job later.”
  • “The ability to pay back debt […] depends upon you writing code that is clean enough to be able to refactor as you come to understand your problem.”
  • Dirty code is to technical debt as the pawn broker is to financial debt. Don’t think you are ever going to get your code back.”

Hence, the important things to remember are:

  1. Debt is bad => if you can get away without it, just do it
  2. Tech debt is a strategic tool => use it under specific circumstances (eg: I need to change this thing and deploy it in an hour, I’ll refactor it right after the deployment), not as an excuse to do sloppy work
    • Remember Fowler => only the quadrant Deliberate/Prudent is acceptable and only for very short timeframes
  3. I’d say that 99.99% of your daily work should be debt free
  4. Unintentional dirty code, missing tests, bad choices will happen anyway, that’s why Norton called it cruft => it’s physiological, but it’s not technical debt
    • In my team, for example, we do code reviews also to catch that
    • Intentional cruft is always a bad choice, something that you need to avoid and that when done shows a lack of professionalism
  5. You have to deal with cruft every day/hour/minute, don’t let it accumulate, because big incremental fixes don’t work => the complexity keeps growing up at the same rate
  6. Clean constantly & follow the Boy Scout RuleLeave the campground cleaner than you found it (of course campground=code)
  7. Monitor your tech debt, also by means of metrics like test coverage, procedural complexity (aka cyclomatic complexity, McCabe number) and cohesion/coupling

I’m not a huge fan of slideshare & viewing slides without attending a presentation, but FWIW Norton has uploaded his slides and they are actually good/helpful. As usual, here you can find my mind map as well.

Mind map of Norton's presentation

This is the mind map that I have taken live during Norton's presentation

About these ads

Tags: , , , , , , ,

2 Responses to “The Technical Debt Trap at Agile Tour Toronto 2010”

  1. Jamie Says:

    The problem, Steve points this out, is that some people actually like debt. Are taught its useful. Let’s face it, most of us have a mortgage and we are happier for it (but would be even happier with a house and *no mortgage*).

    The other thing is this, what is corner cutting? You are assuming that people, with code, even know they are getting into debt. So, just as, when we are kids, we learn rudimentary finance at some point we need to learn rudimentary engineering because currently we don’t even operate at that level.

    Steve’s blog: http://www.m3p.co.uk/blog/2010/07/23/bad-code-isnt-technical-debt-its-an-unhedged-call-option/

  2. thinkingbox Says:

    @Jamie, I don’t necessarily disagree. The big takeaway for me is highlighting the difference between technical debt, which is a tool to use only in very limited circumstances, and cruft.

    WRT educating people rudimentary engineering and what actually cutting corners mean I can’t agree more. :)

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 258 other followers

%d bloggers like this: