Archive for October, 2010

Technical Debt isn’t always Debt

After yesterday’s posts about why you should not focus on reducing technical debt and why that’s not an excuse to ignore it either. Dave brought up a good point in a comment.

Technical debt can be assessed like real debt, to a large degree. How much are you paying monthly because of the debt? An annoying little thing, or wanting to upgrade to a new version just for newness’ sake has a low interest rate.

– Dave Brondsema

But it got me thinking, perhaps “debt” isn’t the right metaphor for this at all. Annoying issues that don’t cost anything, and don’t technically need to be “repaid” aren’t properly debt at all.

Perhaps technical warts would be a better term for those kind of things. It feels good to fix them. But rather than feel righteous for spending time fixing them all and “paying down our debt,” perhaps we ought to feel a little bit self indulgent for spending time and money on what amounts to cosmetic surgery for our code.

I’m not saying cosmetic surgery is never valuable, or that warts are never painful, and certainly not that you should ignore them. After all warts can be cancerous, and could perhaps kill you. But after investigating and discovering that they are benign, perhaps it’s not worth the cost to have them removed.

Ignoring “technical debt” is like playing with dynamite

Earlier today, I posted the somewhat controversial Focusing on Technical Debt is a dead end and apparently I missed some of the subtlety required to get my actual point across.

I still don’t believe that it makes sense to focus on technical debt.

Technical debt is a fact of life, and it’s a sign that you’re writing better code now than you did before. It’s a sign that the team is learning, and that things are getting better. So, you should learn to live with it, or even to celebrate it.

But, that does not mean you should ignore technical debt either.

Technical debt can have real costs, can create real project risk, and most importantly can limit the capacity of the system to produce value. If it’s doing that, you need to fix it. But even then you are better to FOCUS on the long view of increasing the capacity of the system. In other words:

  • Make sure your whole team is learning from the process
  • Make sure you fix the things that impede progress rather than just things that bug you
  • Make sure that you do enough root cause analysis to know why the obstructions got there in the first place

In other words elevate the priority of learning above the need to “fix” things now. That way you’ll avoid future mistakes, get more done, and at the same time continue to deliver value to customers.

In the end I don’t like the term “Technical Debt” as a catch-all because it’s a way of lumping all kinds of different code problems together into one basket which results in trivium being treated with the same seriousness as potentially project destroying technical risks.

So, you do need to pay attention to all technical debt, but some of it should be ignored, some of it should be responded to immediately, and some of it should be “fixed” when you next work on code that touches that thing. Not fixing the critical things is dangerous, and I thought everybody knew that. My point in my last post was that fixing the non-critical things with the same urgency is more insidious danger.

Focusing on it exclusively leads to a weird situation where you’re fixated on the past, and not moving forward anymore. And ultimately it short-circuits the critical thing, which is growing the capacity of the team to deliver value.

Focusing on removing “technical debt” is a dead end

Americans, myself included, have a very short term perspective. Results matter, and this quarter’s results matter most. Perhaps next quarter is important too, heck we might even think a year out.

But we rarely take the *long* view. Push harder and you can make this quarter’s numbers a bit better. Push harder and you’ll get this sale in before the end of the year.

Developers do this too. We push harder to get a product out the door on time, push harder to get a feature in to this release rather than the next.

And here’s one which I think is particularly pernicious, because it seems like long term thinking — push harder to reduce “technical debt” right now.

Technical debt is the distance between how you’d write it knowing what you know now, and how you did write it knowing what you knew then. If you’re constantly focused on fixing past mistakes, you’re not learning the things that will turn the code you’re writing today into “technical debt.”

My recomendation is to focus on other things, focus on solving the problems you’re facing today the best way you know how, focus on cleaning as you go, focus on growing the team’s ability to learn — in other words:

Don’t focus on maximizing the utilization of the system,
focus on growing the capacity of the system.

There are a lot of things in projects I’ve written that I wouldn’t do the same way again. But if I get caught up in fixing every bad API decision in TurboGears or whatever, I would be paralyzed and unable to move forward. Of course it’s not hypothetical, I’ve definitely been there, done that. But I’ve learned from that mistake, and hopefully I can maximize the capacity of the system by helping you to avoid it. ;)