This is a typical exchange during a "Sprint Planning Meeting" between Product and Technology:

Product:

Ok, we have to complete these 10 priority features in addition to the other 5 features that we didn't complete in the last sprint.

Developers:

Ok, but... I think we should spend some time fixing the tech debt from the last 3 sprints which are causing our builds to fail and slow down our productivity.

Product:

Ok, could you explain why this is required and what are the benefits?

Developers:

Sure, we need to fix X otherwise Y breaks, and last time it did we spent an entire week trying to figure out why Z couldn't be updated to the latest version... etc (insert a lot of tech jargon here...).

Product:

I don't really understand what is broken, but fine... how long do you need to fix it?

Developers:

We don't really know... if X works then a week, but then if it doesn't maybe a couple of sprints...

Product:

What? Are you saying that we are not going to be able to deliver any of the 15 priority features that we have in the backlog this sprint?

Developers:

🤷‍♂️ I guess so... or, I think if we do a complete re-write it might only take an extra sprint on top of that.

Product:

Wait what? 🤨

Why is this needed?

Most developers struggle to explain to product teams why addressing tech debt or refactoring code is important and why it is valuable to the company.

Also, most product teams don't consider addressing tech debt as important as features and struggle to get past the tech jargon presented by the engineers. This results in frustration and difficulty during planning sessions.

The Car Analogy 🚗

Most people own a car or have owned a car in the past, so this analogy is easy to relate to and easy to compare to tackling tech debt and codebases that require attention.

👨‍🔧 Cars require regular maintenance, so do codebases.

You are expected to take your car for a service every 10K miles or so for an oil change. We all know what happens to an engine when you don't change the oil. It can cause the engine to run less efficiently, and as time goes on, it can cause the engine components to warp and wear out.

If you don't maintain your codebase regularly then be prepared for expensive and long fixes in the future.

🛑 If your car breaks down, you take it to the garage immediately.

When you see an engine light or your car is making strange noises, you usually take it in for a repair as soon as possible.

If you don't fix your car when something is wrong, it will become unreliable, slow, or simply come to a halt.

Urgent fixes to your codebase must be addressed quickly. The fact that still works today with the issue present doesn't mean it will carry on working tomorrow.

🔧 Check the service history

When buying a used car you usually check the service history and how many owners it had previously to ensure that it was taken care of properly and that there aren't any unexpected repairs to be carried out in the near future.

When codebases have been touched by too many people or the people who wrote the code initially are not around anymore, you will likely inherit a lot of tech debt and issues due to lack of maintenance. If this is the case, expect longer and more difficult fixes.

✨ Cars depreciate fast, Codebases depreciate faster.

The lifespan of a car is very short and they lose most of its value as soon as they get out of the car dealer's door.

When a car is old, you need to consider if spending money on repairs is worth it or if you should buy a new car instead.

Start all over again? but We just moved to framework "X" 4 years ago!

Technology and code depreciate even faster, the technology that was the best and most efficient a couple of years ago could be now obsolete or too slow.

Complete re-writes sometimes are the only sensible option.

Conclusion

If you are a developer, hopefully, you can use the Car analogy on your next planning meeting so you can get that tech debt that you are losing sleep over dealt with.

If you are from a product team and are having a hard time understanding why tech debt is important and you don't understand your technology colleagues, I don't blame you, we as developers don't do a good job at explaining tech debt.