What is Technical Debt and Can You Avoid It?

If you’re in software development, you are going to have to deal with technical debt at some point. So to answer the question in the title…no, you can’t avoid it. However, there are steps you can take to minimize its effects and make sure it doesn’t get out of hand. At least too badly.

What is Technical Debt?

Tech debt, as it’s sometimes called, is essentially the cost you incur over time for having imperfect code. Changes and updates to the source code have a cost, as does adding a new member to the dev team, adding a new feature, or fixing bugs and patching exploits.

As your project gets larger, the codebase expands, and more people work on that code, their voices and styles will clash here and there. Maybe you have a deadline and a less-than-ideal solution is patched into the source code to finish on time. Perhaps you add in an open-source component you don’t fully understand to handle a feature instead of coding it yourself. Or you could switch libraries between versions (from Backbone to React, for example), but still need to support folks using the legacy codebase for their projects.

Absolutely none of these things are bad. Not on their own. Maybe not at all. But when added together, the technical debt they incur is going to have to be paid back at some point in the future.

At some point, that open-source component may need to be replaced (or forked). That will cost time and money. In the distant future, you’ll need to remove all of the Backbone code from your project and stop supporting legacy users. Again, time and money. That patch you did to meet a deadline? Well, it will eventually come undone and need a more permanent fix. Time and money. And you’ll have new members of your team who go back through old code to do all this, needing to understand previous devs’ code and logic. Time. Money.

You get it.

While technical debt is an abstract term, often metaphorical, the cost of tech debt is very real. Paying it back has a monetary value, and you can track the interest you pay on it in work-hours and paystubs. You can see it in the bottom line of all software development.

Can You Avoid Tech Debt?

Like I said before…not really, no. You are going to accrue technical debt in every project you write if you ever go back to the code after its release. However, if you break down the types of technical debt, you can minimize and even account for it in your projects. If you consider the debt beforehand, it’s no different than taking out a car loan or a mortgage. You look at the cost, the interest, and the benefits, and then you decide if you can/want to pay it.

Let’s take a look at some of the examples we discussed above and see if there’s a way to avoid, minimize, or absorb the cost.

Considering Purposeful Technical Debt

When we say purposeful technical debt, what we mean is that your team has made decisions that you know are not within the so-called best practices for either the language or type of project your working on. We mentioned earlier that you might have a deadline to meet. And maybe that deadline is hard and fast. Maybe there is a 0% chance of it being changed or shifted.

This is when you need to consider taking out a loan and going into technical debt.

You really have three options here:

• Put out software that is unfinished and buggy, but you make no concessions for code clarity and logic
• Pull features you can’t manage to perfect, but release what you have that’s as well-written as possible
• Make development decisions that put out “good enough” code to get everything running, but will likely need to be addressed again later

The third option here is often the one people choose. That’s going into technical debt. And there’s nothing wrong with this. Because you made the decision to do it.

Paying Back Purposeful Debt’s Loan

Make sure you document the decisions behind the choice to go this route in your code. Keep notes on what you did versus what the ideal solution would be. And make sure that you include at least some kind of commentary in the source code to indicate where this debt-taking solution was implemented (and if you know, affected systems in other areas of the project). If you don’t take this step, adding to the project (even in bug fixes and patches, not to mention new features or an expanded codebase) can be horribly delayed by finding a patchwork solution when you expect a complete one.

Again, that patchwork solution might be perfectly fine and never give you any real problems. But the technical debt is still there and needs to be accounted for.

Considering Legacy Code Technical Debt

Another common kind of technical debt is one that WordPress is accumulating a lot of right now. WordPress can run on PHP 5.x. The newest update, however, will tell users that it must at least be PHP 5.6. By the end of 2019, the WP Core will require PHP 7.x. However, by pushing the requirements up, a lot of old code has to be updated. Because there is still PHP 5.x code in plugins, themes, and Core itself.

Not to mention the new Block Editor. It’s written in JavaScript. React, specifically. That’s nothing near PHP. In fact, much of the WordPress Core is being re-written into JavaScript, little by little. But all of that JS has to compliment and get along with the PHP, too. Taking on new technology is great, and adopting new versioning requirements is necessary. But in doing so, you’re paying interest on the unavoidable technical debt you incur from that software having been in existence for a while.

Paying Back Legacy Code’s Debt

This one’s kind of tough because there’s not a great way to do it. You could take the nuclear option and do a complete rewrite from the ground up in the new language/framework/version (look at what we did between Divi 2 and Divi 3.0, going from Backbone.js to React). This still doesn’t entirely fix the problem of the debt, however, as you still have people using the old library. At some point, you will have to drop support for the legacy codebase. Which is kind of like paying back the loan. Until you have to take out the next one.

If that’s not an option (or the best idea for you), you can make sure that you don’t rely on language- or version-specific features. Front-end developers have to deal with this all the time, as some browsers support brand new features quickly, while others (Microsoft Edge/IE, cough cough) might never adopt it. You can future-proof your projects by sticking to the basics, which will, in turn, make the number of changes that need to be addressed when upgrading or refactoring fewer than they would be otherwise.

Considering Multiple Developers Over Time

This is a kind of tech debt that large teams tend to accrue over time worse than small dev teams. Though even small ones need to worry about it, too. You see, every software engineer writes code differently. Very rarely will you have two devs that solve the same problem with the exact same code. They may perform the same function, and the end result might be the same, but the code will be written in the voice of the author (just like you can tell who wrote posts here, for instance, as Jason, Nathan, Donjetë, and I all have distinct styles). Code is no different.

Keeping that in mind, the logic can sometimes have different voices, too. What one dev thinks is perfectly clear, another dev will look at and have no idea why the code does what it does. This issue becomes truly problematic when the original author is no longer available to consult. The technical debt accrued by this can be catastrophic. But there are ways to handle it.

Paying Back Old Devs’ Technical Debt

The easiest way is to hire the best devs possible and never let them leave your company. Ever.

Since that’s going to not happen around 100% of the time, paying back this debt can be mitigated a little easier than you may think. First of all, make sure that you train your dev team to comment their code. And to comment it well. Whenever they make a decision that might even remotely be considered ambiguous by someone else, have them note why they did it and how the function works.

Additionally, make sure that every dev on your team sticks to a style guide or set of standards. The WordPress Core has a set of coding standards that will keep plugins, themes, and Core contributions inline so that anyone else coming later won’t have issues with it. Airbnb has a style guide for React that has been adopted as an industry-wide unofficial standard. Even internal style guides and standards keep your devs from going too far on their own because those kinds of commits won’t be merged unless they’re up to snuff.

Wrapping Up

Technical debt is a very real problem. It’s also a very real resource if you know how to manage it. By being able to decide when you take on tech debt and how you pay it back, your development can go quicker and smoother than otherwise possible. And in those times when taking on that burden is unavoidable, we hope that we’ve given you some ideas of strategies that you can implement to make it less impactful than it might otherwise be.

How do you handle technical debt within your projects and dev teams?

Article featured image by Andrey Suslov/ shutterstock.com