Every person in IT / Tech has experienced it. We've all contributed to it as well. But what is Technical Debt? How exactly does it come about, and how can it be addressed?

Definition

According to the Wikipedia, Technical Debt is defined as;

...a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

https://en.wikipedia.org/wiki/Technical_debt

In "plain old English", this means that somewhere corners have been cut, or things were "put on the shelf" for later review

How does this happen?

Surely everyone plans each project, gets a full specification before beginning. From there, the teams are assigned tasks and then the sprints happen. A true Agile wonderland. Everything gets built, delivered, payments made for the time and work. Afterwards, we all go out for a drink and celebrate the latest product.

No. Nope. Never. Get out. This will categorically never happen. I'll happily waiver my entire life's possessions on this fact. If you believe that this is going to happen, you're in for a shock my friend.

In my 8 years of development, I've only seen a complete Technical Specification once. That's not an exaggeration. I remember the day very well.

Beyond that, there's going to be an aspect of human error in the code / programming that goes on for the change / product. There will be times when someone asks for a change in the future, or a new feature, and the Lead Developer / Tech Lead will say "We now know how we should have done it", or something to that effect.

Ultimately, Technical Debt falls into one of 4 categories;

Reckless and deliberate, aka., "No time to do scope the database architecture out"

Reckless and inadvertent, aka., "I don't know how to scope a database architecture"

Prudent and deliberate, aka., "Get it working, we'll clean up the database later"

Prudent and inadvertent, aka., "I've learned how to architect databases, we should go back through this project now"

Evasion / Prevention

Get all projects outlined and agreed - by all concerned parties - at all stages. Any change will trigger a Change Request, and will only be started after the previously signed document is completed.

Yes, you will have stages in that projects will be built to something that is not the final product - however, you'll find that clients are far more concerned with the specification when you tell them that it's the final line and anything outside of it is chargeable.

Be open and honest when looking at proposals and projects. If you know that something isn't quite right and could cause issues down the line - raise it to whomever is going to end up paying the bill. They'll appreciate the honesty and often allow you more time to get it right.

I have unfortunately seen some Agencies open advocate Technical Debt; purely for the "recurring invoice" factor. If you build it one way, you know that the client will have to come back again in a few months to change something. Dirty tactic. Stop doing it Agencies, you're giving us all a bad name.

Measuring Technical Debt

As Technical Debt isn't something you can physically measure, a lot of it is conceptual; giving it any kind of value can be troublesome.

You can use tools to inspect your code, these will give out scores about cyclic complexity, and general "cleanliness" of the code base. A couple of my personal favourites are;

https://github.com/nunomaduro/phpinsights

https://www.phpmetrics.org/

Addressing the Problem

You've established you have technical debt - what are you going to do about it?

Pay it off, naturally - it's a debt. Leaving it alone will only increase it. Technical Debt, in the same way that financial debt works, accrues interest over time. For me, every day Tech Debt is left, add 5% day to the fix time.

To best approach technical debt, you first need Tests. This is to ensure that your code produces the same results after, as it did before. If you don't have a test suite for your application already, that's another Technical Debt!

Once you've got your tests, refactor can begin. Ensure that your tests are working, and then do a further test with a Browser / Postman / Insomnia client.

Get it live. Ensure that you are ready to roll back the changes though, Technical Debt has a nice way of giving you "unforeseen" impacts. Especially if you're inheriting the code base from a previous developer who is no longer available for consultation.

There is always the "Destruction Testing" method. Comment out the code, what breaks. Fix that. It's a risky one, but I've used it in the past and it works a treat. Just be prepared to catch a lot of Exceptions in Sentry, HoneyBadger (whatever your Error Catching software preferences are). Users will quickly alert you to these errors, and if they don't - you get them anyway.