Paying down debt (financial, technical, and otherwise)

Debt is a complicated subject.  On the one hand, it is empowering — it lets you get a quick start on something, and lets you do things that would not be possible otherwise.  There are times when it is useful, necessary, and unavoidable.

I think about “debt” in the broadest possible terms: times when you are left “owing somebody” (including yourself) for something.  My inbox is in a state of debt right now.  The pile of unsubmitted medical bills on my desk is debt.  Duct tape & bubble gum holding up v0.1 of an app is debt.  Friends or family you haven’t called in a while is debt.  Not to mention financial debt, which comes in many flavors.

I am actually a fan of incurring “technical debt”, especially in the early days of a project, when you are iterating quickly and you are not yet sure what the long-term architecture of your product should be. I think a “get something up and running quickly” attitude is often best.  So taking on this kind of debt early is a strategic choice that if, done well, can actually save you time and/or money in the long run. 

The challenge with debt, of course, is paying it down.  

It seems as though one of the characteristics of debt is that you overestimate the short-term benefit and underestimate the long-term cost.  The result being that it’s easy for things to get out of control, slowly and then quickly.   This article on the nature of a “debt spiral” covers it well.

I always think about paying down debt at the end of the year, as it feels like a time to try and get the house in order and work on a fresh start on the new year.  I don’t like “rolling over” debts (at least the kind I can really control in the short-term) into the new year.  So I am doing my best to grind through and catch up on things now.

But better than getting in debt, and then getting out of it, is figuring out how to stay ahead of it.  And again, I don’t just mean financial but in every way.  Replying to an email before someone pings you with a reminder.  Checking in on a friend or family member without them asking.  Dealing with bills and expenses as they come in.  Or even better, building capital: write a blog post, build v2 of that app, publish that presentation, make the budget, contribute to your savings or 401k.  Proactively paying ahead.  

Easier said than done, like most things.

6 comments on “Paying down debt (financial, technical, and otherwise)”

There comes a point when a company becomes so indebted to a bank that the bank will not allow the company to fail. The fate of one is the fate of another. Debt as glue?

Great post. In the past I kept running into technical debt and was told it is inevitable. I feel this is somewhat true and somewhat false. I’m a proponent of Scrum and have been studying it more and more over the past year, trying to pull it into all aspects of my life as possible.

One thing my father fault me that helped me later in life as a creative director was to make sure I did things right the first time. Because it will cause you to keep coming back to the issue later, possibly multiple times over, causing you to take on more and more debt.

I am a list maker and then I execute as fast as I can but trying to do it right without spending too much time.

In the book, “Scrum: The Art of Doing Twice the Work in Half the Time,” by Jeff & J.J. Sutherland, they discuss the topic of debt and recommend the following…

“Do It Right the First Time. When you make a mistake, fix it right away. Stop everything else and address it. Fixing it later can take you more than twenty times longer than if you fix it now.”

This is something that I find to be very helpful in dealing with non-financial debt.

I guess my feeling on technical debt is that the flip side of that is over-planning. designing for future scenarios that just aren’t relevant today. optimizing too early. I see that happen all the time, and I’d always rather have a working product with some technical debt than a perfectly design, architected, optimized thing that is actually the wrong thing

that said, your point is well taken, and in the best scenario, you stay agile and build well as you go

>…over-planning. designing for future scenarios that just aren’t relevant today. optimizing too early.

I hear ya on that… A lot of developers are guilty of this. Especially those working in very small groups. I’ve seen everyone do it from time to time. God knows I am guilty of doing it from time to time as well.

These days, I’m trying to apply the “plan” quickly “OODA loop” model to my decision making and planning. Orient, Observe, Decide, Act and then loop. It was developed in air-to-air combat during the Korean War and gave American fighters an edge over their much faster, more maneuverable MiG-15 adversaries. Minimal planning is necessary (checklists) but more important is to push and get feedback to make the product better as quickly as possible.

Comments are closed.