Welcome to my new series on Technical Debt. This topic gets brought up a lot, and just as frequently dismissed. The reality of technical debt in the modern platform-era is more critical than ever for organizations to understand and mitigate. This is a multi-part blog series that will cover a number of facets of technical debt: real world scenarios, examples, and strategies for overcoming that debt through partnering, internal review, and the “build v buy” dilemma.
My treatment of debt is probably something different, as I am taking a tack of addressing the investment in that debt. Like junk bonds, or sovereign debt, technical debt can be an investment class that a technical organization makes a known investment in to create short term gains. Just as often though, the short term gains can evaporate in long term losses as the debt burden cannot be repaid. Knowing how to steer these investments and to make sure that plans to mitigate the debt load are in place is the difference, and what this series covers. So without further adieu, session 1.
Session 1 – The Platform as Investment Grade Debt
Why would you choose to partner with a platform provider instead of building a solution
yourself? This fundamental question faces developers more and more every day and the answers are not always clear. There are many factors that influence this decision. You have to carefully evaluate the capability of the platform, the strength of the company, and the ability of the company to deliver. None of these is a “light” consideration and they all need to be carefully weighed and understood. Unfortunately, none of those considerations address the most critical element of ANY technical decision; the accumulation of technical debt.
Technical debt is the idea that as you build software you will find yourself faced with the need to choose something “easy” or something “right”. Unfortunately, the “easy” option often prevails even if the “right” option was better. This results in a codebase littered with “easy” options that need to be fixed later to be “right”. The financial market comparison is apt here, because as the name implies, you are investing heavily in debt-backed instruments. They can definitely pay off in the short run, but when they are exposed, they will cause major impact in your portfolio.
Doubling down on debt
The core principle of this definition is right, and in particular the “financial market” element it implies. My assertion is that it does not go far enough in describing the reality of the debt load created in the aftermath of technology decisions. While the focus ie primarily on decisions developers make about ways to write a bit of code to solve a challenge, the reality is that technical debt is created through ANY decision involving your technology, including right down to the personnel. All organizations using technology have some level of technical debt. That “debt load” can be a heavy burden and will only become impactful when the debt has to be paid. The tricky thing about technical debt is that until it is exposed, it can seem to not exist. Be assured that it is always there and has real impact on this discussion.
Your technical debt is analogous to owning a house (or any fixed asset). You accrue more the longer you hold the asset, and only get to realize the gain when you transfer the asset (sell the house). You can borrow against the value of the asset, and you can use that gain to improve the asset, increasing its value. This works the same with technical debt, the longer you hold it, the more it accrues. Unfortunately, what people don’t often understand is that technical debt only accrues in the loss column.
Debt in action
Let’s see a simple example in action:
|Typical debt||Technical debt|
|You bought an asset – in this case a house from a home builder.||Your lone developer builds an application or platform or features|
|The house value went up, so you take a home equity loan and upgraded the kitchen||The developer learns HTML5, and React and uses that skill to improve the application or platform|
Now here’s where everything shifts:
The housing market crashes
Your lone developer leaves and takes all the investment with them in the form of skills and knowledge
|You still have a house and the market will recover so you stay put and enjoy your house (because it’s still a house)||Your application runs in its current state and you have to find someone to replace all that skill – they have an immense learning curve for your particular application even if they know React and HTML5, because it was originally built on older technology|
|You wait it out and even re-fi to get lower rates during the dip – you even make a few small improvements since prices on building materials drops||Once your new developer is up to speed, you have fallen behind in features and needs, and now catching up starts while the market moves ahead|
|You eventually are able to sell the house and recover your investments along the way, thus your asset has appreciated||Maybe you catch up and maybe not. The damage is done either way, and the technical debt is felt as a loss, even if you are able to catch up, in lost opportunity.|
Obviously, this is a gross oversimplification of the housing market, however it illustrates the point about technical debt. There is no point at which “the market” recovers for technical debt loads. You have technical debt the second you make a decision about your platform and tech stack. That impact simply doesn’t exist outside of technology and it is the biggest factor in the overall build vs buy decision that must be considered. So why don’t we focus on this debt more?
Asking the right question about a platform
Unfortunately, the foremost question everyone asks when evaluating build versus buy is not “what debts does this create?” Instead the focus is on the platform and its ability to help overcome the hurdles to completing your own solutions. Does it give you an advantage or help you produce something you otherwise could not? Is there a feature set that provides significant advancement in terms of time and effort? Can you work the platform into your overall vision for you own environment? Understanding the answers to these questions and digging into the features and functions are obviously of great importance. However they completely miss the critical question of the debt load that comes with this decision.
The better questions to ask about a build versus buy decision are along the lines of the debt that each will incur:
Can my existing team, with their current skills, work with this platform? If not then I have automatically created additional technical debt which I must now overcome. Generally the vendor will have training and support options. (If not, you probably want to steer clear!) Do those options allow my team to acquire the missing skills quickly? If I suffer turnover, how long do I lose those skills? (ie. how often is the training made available?) Is the skill set required to use the platform common or highly specialized? If it is to specialized I may not be able to repay the debt load down the road if something changes.
Ask the vendor:
Does the vendor have enough strength to manage their own technical debt? Do they have a good track record of growth and steady development cycles? Are they aggressive or keep things status quo for their releases? All of this can indicate that the partner you are evaluating has managed to account for their own technical debt load internally. Have they addressed the issues of the marketplace and changes in technology effectively? Technical debt also comes in the form of a “trade imbalance” in the open market. Platforms and programs that are not on pace with the market mean more debt load. That means you start in the hole before you even begin.
Looking for the Debt Relief
Technical debt is like an iceberg in that most of what you have, you cannot see. It is growing across all sectors of technology as the demands for features and functions increase. There are not enough man-hours in the day to create everything from scratch. Increasingly the build versus buy question is being asked as organizations evaluate the need for a feature-rich experience. It is imperative that that line of questioning includes a deeper exploration of the possible technical debt it can create. All technical decisions create some amount of technical debt. The decision has to be to mitigate the debt risk and find the investment that provides the greatest return.