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. ;)

9 Responses to “Focusing on removing “technical debt” is a dead end”

While I agree with this post, many programmers are paid by clients/bosses who measure results by the utility, not the capacity.

Many of us have to juggle between giving what the client wants now (utility) while still maintaining some capacity they can’t (don’t want) measure so that you can keep giving the utility they will want in the future.

Achieving a balance between utility and capacity in that kind of setting is something I really would like to learn.

That’s a common issue. In the case of a client it’s pretty easy to see why increasing capacity is a key goal for both sides.

Capacity is the ability to deliver useful features (value) to customers regularly and predictably. You’re right customers don’t care about your team’s total capacity, but they do care about features delivered predictably, and quickly.

With a boss who measures utility now, not capacity, you are in a harder place. From my point of view there’s two choices either they can be convinced by growing the teams capacity while still delivering features, or they are a lost cause.

If you can do iterations and retrospectives, and actually have a team that learns to do better each time, you will see results. Results in terms of more utility delivered per iteration, which bosses see.

But if your boss doesn’t understand real retrospectives, real iterations, and real learning can be hard to do, because all of the require people to stretch and take risks. Bad managers make those risks harder, and stunt the ability of team-members to recognize their own mistakes, give critical feedback to one another, to change broken processes, and ultimately leads to a failure to learn.

If your “technical debt” is preventing you from moving forward at an appropriate pace, then you should ignore the above advice and focus on it. Especially if said technical debt is poor or non-existant unit test coverage, slow-running tests or tests with intermittent failures, an architecture you have outgrown, and many many other things one would normally refer to as “technical debt”.

I think that’s very clearly part of what I’m saying above. Growing the capacity of the system can require changes to the software, and you should do those things. But “removing technical debt” as a catch all, leads you to stop moving forward with delivering value to your customer, and stop learning new things.

It’s not that you should never fix things, but that you should clean up what you need to clean up to get new stuff done efficiently. The difference is focus. Do you focus on the eliminating debt, or the growing the capacity of the system?

> 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.

That’s only one kind of technical debt. It’s probably the most painful kind, but it’s not the only kind. I’ve seen that kind referred to as “credit card technical debt”–the kind you didn’t see pile up until you get the bill at the end of the month.

There’s also the technical debt of “I know this isn’t the way it should be, and it’s fairly clear what the right solution is, but the right solution doesn’t fit into our time/money/attention budget. So we will do it this way, and plan to revisit it at a later date.” That’s the “mortgage” kind of technical debt. This commonly shows up in the form of implementing only the portion of a standard that you know you need right now, and eventually expanding support to cover the rest of the standard later. It’s less dangerous than “credit card” technical debt–so long as you really do take care of the unfinished business before it’s too late.

But your post overall sounds like you’ve never worked on a project in which the cost of servicing the accumulated technical debt *prevented* you from doing work that expanded the project’s capacity.

I’ve worked on projects where “the cost of servicing the accumulated technical debt *prevented* you from doing work that expanded the project’s capacity.”

Even then I’m convinced that the key to getting out of the weeds is not to focus on paying down technical debt. The way out is to grow capacity, while at the same time mitigating or eliminating barriers to forward progress.

My point is that the “technical debt” metaphor is actually used (unintentionally) as a barrier to forward progress, and cleanup that starts quick and easy ends up eating up huge number of cycles, and keeping the team from growing and learning.