Managing Technical Debt Is No Different Than Managing Health Debt

Like many children I’ve been in sports from a young age. I began with swimming which I’ve done from the age of six. I then immersed myself in many other activities such as Street Workout, Gymnastics & MMA.

Having a young and healthy body enabled training around five times a week without getting injured even once while not managing my weak spots. I didn’t even know what they were! I was collecting debt in the form of technical movement imperfections and strength imbalances. I also did not have a coach to notice those imperfections and manage the debt.

Eventually life punched me in the face. My body gave up and I found myself with a torn labrum, preparing for surgery. Unable to train, and unwilling to be honest, my strength, mobility and agility all deteriorated.

The injury, in the long term, set me back a couple of years worth of progress. Even though I eventually did recover, and currently am active, it took me significant time and work to get back on the horse and to my previous shape while making sure I do not repeat the same mistake.

I believe in creating my own luck — good luck as well as bad luck. Working on complex movements and incorporating multiple training modalities such as Gymnastics and Weight Lifting together required working on my weak spots.

It required performing proper worm ups, having a mobility routine, doing targeted exercises at the limit of range of motion, strengthening stabilizing muscles and more. Dismissing the above and not taking it seriously enough paved the road to injury.

Strong, and ever improving, foundation allows complex and challenging movements. Software is no different. At the beginning of a software project you can hack your way, sort to speak, into delivering very fast. You can do quick and dirty. I even argue that you should!

However, as you continue writing more code and adding complexity you should have a road map towards a more robust architecture, as robust as needed at any certain point in time. That road is parallel to tech debt town. Failing to attend to you technical debt will slow down development dramatically at best and blow up the entire project at worst.

I did not attend my physical debt and it cost me a lot. Project “I can train without worrying about weaknesses” was a total flop. And it hurt.

Take Stock Of Your Debt

Notice your debt and be conscious of it. Then, create a tech debt backlog just like you have a feature backlog. List all the architectural shortcomings and compromises there, small or large.

It should contain all sorts of debts:

• Code that did not get it’s own module and now makes the code-base that much too coupled.
• The not so generic solution that is now impeding progress due to new business use cases.
• The adapter you did not write and now your code-base is couple to some specific library or SaaS.
• That module which you left untested because of a pressing deadline.

Taking stock of your debt in any area of life is a good idea. In Jordan Peterson’s 12 Rules For Life he says that we should take stock of ourselves. Just like you bring an inspector to evaluate the damage done to a house you are buying. You don’t want the house tumbling on your head some day without notice. You want to be aware of it’s imperfections. You don’t want your software failing in production without you at least anticipating it. Be the inspector — list your debt.

Prioritize Your Debt

There is always an infinite amount of debt. There are also countless bugs to fix and features to develop. Just like you are not doing random features but rather work to improve your KPIs, you should prioritize you debt before attending to it.

A good rule of thumb would be — what is most painful to the dev team and easiest to fix — there are plenty of those usually. Just like you should prioritize a targeted strength exercises and mobility drills — you can’t do them all at each session.

Eliminate Debt Consistently

Since debt as a whole is not going anywhere, since you are always adding complexity — you should consistently attend to it. A bad way to eliminating debt would be “doing tech debt sprints”. Although sometimes necessary, it should be the exception. Developers do not like working on tech debt all week long. They like seeing their features get to production and impact the products and it’s users. Just like you would not do a workout which doesn’t have your target exercise but rather only address your weaknesses.

Devote 20% of your time to technical debt. Or 30%, in the macro it doesn’t really matter. Do it consistently and you will deliver faster and have happier developers than you have ever had.

Moreover, when you are a developer working on a task, and you notice some not so perfect piece of code that is impeding your progress try estimating whether you can clear up some debt “on the way”. Maybe even in exchange for a little delay in the deadline. It is a tight road to walk between a small refactor “on the way” and an entire hidden task within the original task.

It takes time to develop intuition as to which one it is. And you will always get it wrong sometimes anyway. Be compassionate with yourself when you misjudge.

Take Home Message

Staying relevant in the long run requires constantly attending to your imperfections. Whether you are writing code, working out or working on any project.

Making the process of eliminating debt systematic and habitual allows you to focus your resources on doing meaningful and productive work rather than putting out occasional ‘fires’.