Posted in Software & Development
September 15, 2021
Technical debt: Why it's bad and how to avoid it
Listen to the podcast
Listen to this post using the player, or subscribe using Spotify, Apple Podcasts, or Google Podcasts.
Technical debt refers to less-than-optimal code that becomes increasingly problematic over time. It's actually pretty common: you develop a minimal viable product (MVP), and as you add on or make changes, it gets to a point where if you could go back and rearchitect the whole thing, you would do it differently. Your architecture gets progressively weaker and weaker.
It's important to take the time to reduce your technical debt so you can clean up your code and make future development faster and easier. You usually get improved performance too.
Convincing clients to invest in addressing their technical debt can be a tough sell, however, largely because it doesn't come with an immediate payoff. What new features come with it? None. What will be different? Nothing, essentially.
After all, what do you get by paying down any other kind of debt? Nothing tangible—you already live in the house or own the car. But getting rid of debt so you don't have it anymore is a big relief. For one thing, it means you're not continuing to accrue more debt, which gets worse and worse over time.
How do you get rid of technical debt?
You fix those things that need to be changed. Say we have one feature, and then we add three more features. If we take the base and rearchitect it, we can remove 800 lines of code. We can make one common base and not have to maintain four individual features. That way, if we want to add a new feature, it's fairly easy because we don't have to recopy a whole bunch of code. Maintaining a single base also makes bug fixes easier.
But the actual process of rearchitecting doesn't get you anything right away. That's why it can be tempting to put off dealing with technical debt and just say you'll get it next time. And next time turns into next month and next month turns into whenever and it just snowballs.
Technical debt is very manageable if you stay on top of it, but it gets troublesome if you put it off or ignore it. Consolidating base code for four features takes time, but leaving it until you have 15 features is a much bigger deal.
It's true that it's not always possible to do little bits of technical debt cleanup. Maybe a feature worked fine when it was first implemented, but as you've gone along and added more features, or a client's needs changed, or the technology advanced or improved, you realize the code should be rearchitected.
What does rearchitecting mean?
It means consolidating things, moving pieces around, and maybe changing how stuff works. Sometimes you need to remove old code for features that aren’t used anymore, for instance.
Think of the rule of three: if you do something once, there's no point in abstracting it out into a reusable function cause that's just wasted time. If you use it two times, it's probably still not worth it. But once you use it three times, it would likely be more effective to make it into a central shared thing. This is not a hard and fast rule but a good guideline.
The idea is to make the code simpler and more streamlined. Complex code is bad code.
TLDR: Don't let your technical debt compound over time. Fix it before it gets out of hand.
More from Acro Commerce
- High Five video: Automated Drupal Code Testing: What, Why and When To Do It
- Tech Talk video: Drupal Website Debugging and Site Performance
- Learn more about Acro Commerce
Chat with us
If you'd like to talk about optimizing your Drupal Commerce website, or if you just want to discuss how Drupal Commerce fits into your ecommerce solution, give us a shout. We're happy to chat.
Editor's note: This was originally published on April 17, 2018, and has been updated for freshness and accuracy. Enjoy!