It’s a nasty little problem that plagues even the most “buttoned up” of engineering teams.
The easiest way to define it is the tradeoff between choosing an easy engineering solution now compared to taking a better approach that would take longer. Market pressures and tight deadlines forces your hand, causing you to make decisions in the name of expediency and getting a product to market.
The truth is that if you waited to do things perfectly every time, nothing would ever get done.
But for every shortcut, there’s a price to be paid. There’s nothing wrong with technical debt as long as you keep that fact in mind.
Like any debt, accumulated technical debt, with no plan to pay it back, leads to disaster. The more you accumulate, the harder it is to make changes. Obstacles manifests itself as bugs, rework, and ultimately missed release dates.
Not fun.
At R&Y Labs, we like to see Technical Debt a bit differently. We see every single line of code we write a technical debt, regardless of whether it’s “clean” or not. As soon as you put down any code, it will have bugs. We are firm believers in the common saying:
“To write bug-free code is to write no code at all”
This should be the adopted mindset a development leader, founder, or product owner. Bugs and errors in code is an inevitability; if you embrace them as such, it helps you make conscious decisions born out of strategic thinking, creating a plan to account for them and mitigate them.
Let me explain —
The most popular approach for engineers is to “pay back” that debt by refactoring code and cleaning it up. This is done in controlled, scheduled bouts.
The other approach, popular to many product owners, is to keep putting it off until your app is eventually unusable. But that’s like saying “I’m too busy to remove this nail from my forehead” It’s simply not sustainable.
But there is a third (and often overlooked) solution.
The ideal is to remove the code and minimize the technical footprint that you have. It’s not easy, but it’s the only way to truly eliminate technical debt.
When we pay off technical debt by refactoring code, it’s really like refinancing your house. You’re not eliminating the debt, you’re just lowering your payments. The only real way to fully eliminate technical debt is to get rid of the code altogether. It’s not always possible, but is often a solution thrown out too readily.
Engineers always think they’re building a unicorn. Project managers always think they’re building something unique. The reality is that a good portion of what we build has been done before. We justify build versus buy (and in this open source age, versus use) by explaining that something doesn’t do a thing we need or we’ve already built a good portion of it, but really we just want to take a shot at re-inventing the wheel.
As a technical leader, the question you should ask yourself is, “does this thing we’re building define our company?”. If this code your team puts down will later become a liability, does it make sense to take this on?
Our perspective on technical debt has led us to another revelation:
The amount of technical debt that you can take on should be proportionate to the projected size of your technical organization.
If you’re a growing tech startup receiving funding, you can afford to take on more debt knowing that you’ll eventually have the manpower to pay back that debt. If you raise a big round, you can even take on more debt faster.
Pretty simple right?
The subtle part of the rule is the inverse; what if tech plays a supporting role?
Or what if your startup stalls and you’re left with a massive pile of technical debt that you can’t pay off?
When Calvin ran the technical team for a VC funded tech company, they had plans of growing the development team, and took on technical debt because they knew they were going to hire more engineers.
The problem is when the focus changed and the business pivoted, rather than pulling the plug and writing the old tech it off, they continued to support the old business as well as take on the pivot. All while abandoning the original growth plan (this is one reason a clean pivot is preferred, it gives you a way to jettison technical debt). When the startup evolved and became a mature company, they had to make a decision to shed the weight of that legacy code because they simply couldn’t manage it and still run day to day operations.
And what if you’re not a startup? What if you’re POBO (Plain Old Business Object)?
We once had a project working with a large civic organization in Atlanta. Part of the project involved integrating with a custom CMS (Content Management System) built by a third party. When we looked under the hood, we discovered that it was built in a way that contained a lot of dependencies and needed constant maintenance. This for an organization that had zero development resources (they did have an IT organization to handle typical IT things). This was a total mismatch in technology applied vs organization’s technical capabilities.
The lesson to be learned is this: if you’re a technology leader, understand what your company is and where it is in heading. And factor that in when deciding how to apply technology.
If you’re a technology leader, or a owner of a technology product, how you manage tech debt will be one of the most important challenges you will face. Even if you do have a large budget and a plan to ramp up your development organization, managing this issue well will not only help you speed to market, but help you speed the right things to market.
