This post is from a speech I gave during the Vancouver PHP Meetup (if you're in the Vancouver area please do join us!) in March 2018.

Definition

Technical debt is like financial debt
- Ward Cunningham

Like financial debt where you have interests payment, technical debt will give make you put extra effort for future development. You can chose to pay it by doing nothing or you can pay down by refactoring. If you pay down it’s gonna be more costly at first, but you'll have reduced interest payment in the future.

But if you have debt with a bank, you can talk to someone, negotiate, and agree on a payment plan.

Technical debt is like debt with the mob
- Alberto Brandolini

They will come at night, pointing a gun to your head, and they want their money NOW. Try to ignore it and you will lose many developers or even worse you'll lose everything.

From the customer view or even product owner, everything seems good, but devs will know what's up and what they have to deal with on regular basis, trying to manage it to manage security issues, bugs, and quality code.

Why should you even care about it?

Ever heard of the Broken window theory? Andrew Hunt and David Thomas, in their book The Pragmatic Programmer, make a powerful demonstration using this theory. Basically even if the best written piece of code contains one area where the code is bad, any developer working on this will allow themselves to put bad code as well: “Why even bother? The other dev didn't bother...”.

How many times did you hear : “Aw man, I think it would be better to restart from scratch (in Language X)” ? Many young  or unexperimented programmers tend to think that if you re-write from scratch the application it will be only better. But if you don't have any plan to manage technical debt, you'll be back to square one with your good ol' technical debt. And you spent a lot of money for nothing.

Working with too much technical debt or not well contained makes you spend too much effort and overhead when developing new features.

Because of all of that you should care about technical debt, you'll end up spending more and more money just to get things done slower and slower. Technical debt is also making your dev's life a nightmare and can hurt their dedication to deliver good quality software, or even making them go away from your company.

How to manage

Managing technical is all about to make it visible. How many @todo's you have in code that you don't even remember why you wrote them or if they are still relevant?

One way of keeping an eyes on things and know the current "health" of your application is to follow those steps:

1. Identify
2. List it
3. Evaluate the cost
4. Assign
5. Monitor

Those steps allows to keep track of the technical debt while doing regular business activity and putting a cost on the technical debt to make it visible to other company's team. That way you have more leverage whenever you need to make understand upper management or product/business team why it will take this amount of time. I want to insist on the benefit of having a cost established (even if it's a rough estimate), because it easier for non technical people to understand what we are talking about and how it is impacting their business.

Keeping a Jira, Trello or whatever ticket management tool (usually the one you are already using) is the best option because you can draw a velocity chart from that and it is a good visual indicator.

Contain technical debt

Because it's not possible to eliminate totally the technical debt you can only fight it to contain it to the smallest amount possible.

You have to train your team to follow some basic rules, because it is easier to do it as you go than rather try to do everything at once.

Always leave the code cleaner than you found it

AKA the boys scout rule. Working on some code but 10 lines above/under you see some quick improvement to make? You don't see any unit tests for the code you're trying to understand? Do it. Your future you will thanks you.

One battle at the time

Don't overdo it, stay focus and don't try to fix everything at once, you will likely end up in a rabbit hole. You still need to deliver this new feature or fix the bug.

It's everybody responsibility

Useless blaming won't get you far, everybody is responsible for the code delivered. Who cares that the gone dev did a shitty job? We shouldn't judge because your code might be tomorrow's shitty code anyway. The code is here anyway and won't go away.

Also please make sure everybody in the company is onboard to take responsibility on fighting the technical debt. Code is only a translation of what's happening internally in the company. Usually complex, shady, and undocumented code is a mirror of communication between team being bad.

Prevent it

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
- John Woods

Keep that in mind.

Remember the broken window effect? Have a clean code to prevent any dirty change, or at least make them more obvious so that it can be caught during code review.

Speaking about code review, make them better. Aim for:

• Simplicity
• Smaller change of sets
• Nested loops => 🙅‍♂️
• If/else => 🙅‍♀️
• No tests => 🙅‍♂️

Management needs to understand that, dev teams are more confident introducing features when tests are here. So more tests doesn't mean less features. Quite the opposite actually, with actual tests you deliver faster.

But more importantly make the technical debt visible from everybody, so everybody can have a grasp of what technical people are complaining.

Sources

http://verraes.net/2014/06/managed-technical-debt-revisited/
http://slides.com/maximethoonsen/agile-technical-debt-forum-php
https://blog.smartbear.com/code-review/the-secret-to-code-quality/