The costs of doing business are high for any size company, and they’re growing higher the more tech savvy we get. Beyond the obvious costs of employee compensation and general operations, there’s another cost of business that needs to be considered, but can sometimes be overlooked: technical debt.
What is tech debt? There is no one official definition, but at its highest level, it’s cost (time and resources) incurred when making modifications or enhancements to your systems. It can be as simple as having built two functions that perform an identical operation, or maintaining an app on an old version of the operating system’s language. In other words it’s a decision you made in the past that is holding you back from innovating. Issuing a software update or performing another form of routine maintenance is not tech debt.
I see it as the result of poor communication and planning, coupled with overly complex systems and evolving requirements. It can be problematic, but it can also be healthy when managed properly.
Let’s take a look at how to incur and manage tech debt.
Some level of tech debt is healthy
In many ways, if you don’t have tech debt, you don’t have a dynamic, growing organization. As business directions and priorities evolve, it only makes sense that products and features change as well. Engineers need to be flexible, and shift priorities when the business shifts. That may mean making a strategic decision not to invest heavily in a certain feature if it’s no longer a priority and take on some debt. Or, there will be times when an engineer needs to change a timeline and ship a product sooner than planned, leaving many great features on the cutting room floor, and possibly incurring some debt.
No matter the cause for the debt, face it, clearly talk about it, and build a plan to isolate or move it out of your way in order to reduce impact, and have a plan to pay it back when the time is right.
Old code does not equal tech debt
You might assume old code means tech debt. But, that’s not always true. The old adage, “If it ain’t broke, don’t fix it,” may well have been said about tech debt. If you have a system running without issue for years and you make very little investments in it, there is likely little to no debt there.
For example, almost 10 years ago, I wrote a process to import questions and answers on Trulia into a searchable document store. We had grand visions of how we would change or expand the search capabilities over time and make it real-time, but the reality is that the search functionality worked well enough as it was. In other words, the latency I worried about upfront never had a meaningful impact. That job continues to run today and we leave it be.
Debt is added not from the age of the code, but the way you write it. Build for a minimum viable product instead of building with the assumption that the feature will be expanded upon because you never know when things will change and what once was a priority for the company no longer is.
Tech debt also comes from poor documentation and communication. If you have a small team working on a feature and the entire team moves on to new projects or companies without having documented the intention of the code, you’ll have new engineers coming in and building off assumptions. That’s never good.
When someone new comes in and doesn’t understand the reason behind some code, they will likely abandon the code and write their own, which leads to multiple ways of doing the same thing, compounding the amount of your tech debt.
The solution for reducing tech debt is communication
Like many things in life, the key to fixing tech debt is communication.
Start by building engineering principles. These can be your guardrails for what’s right or wrong, and what’s in or out of bounds. For example, mandate automated tests to catch regressions, and alert of failures and performance degradation; have consistent code and architecture reviews; or, build principles related to documentation, explaining why you built something the way you did, not just what it does. Align your team across these principles and the group will function much more effectively, and help unify the discord between the old and new way of doing things.
Good intent and great execution don’t necessarily mean you’re going to avoid tech debt. If an engineer is working as a solo artist, they may create tech debt by duplicating efforts. If there aren’t healthy debates about how to move a project forward, you can invite tech debt. Often there aren’t perfect solutions, just trade offs. But by working as a team, and agreeing upon principles, you can reduce the focus on tech debt and instead move forward to the exciting part of the job: building something new.
