Tech Debt is Good
What is a technical line of credit?
Technical debt is often treated entirely incorrectly. It is observed as a sign of antiquated culture, bad practices and hurried architecture. For most tech professionals this sounds obvious, and have you ever bought or leased an automobile?
I went to my favorite car dealer several years ago and leased a brand new car. We worked out option packages and mileage, down payment and monthly payments. I gave them my down payment of only $5,000USD and I walked away with a $50,000 automobile.
Let’s translate that exchange into application ownership.
I went to my development team several years ago and asked for a brand new application. We worked out the amount of sprints, time and cost to build. I gave them the time to build it and after only 6 months my startup walked away with an application capable of handling our million dollar idea.
After I bought my car, my bank followed up with me every month asking for a payment. I didn’t walk away from the dealership for just my initial $5,000 payment and no follow up payments on principal and interest. You must service your debt.
Our technical workloads don’t only accumulate debt. Instead, they accumulate interest on existing debt.
This unpaid interest is what many people are often referring to when they think of tech debt. From the first line of code, a new project begins accumulating debt; but the interest hasn’t come due, yet.
We don’t buy our applications, even from internally sourced development teams.
We lease them. They require interest payments in the form of package upgrades, architecture changes and security posture alignments. The debt and interest rates we take on at the inception of the idea can be known and must be planned for.
There is no “bank” that’s going to ask for the work to be completed to pay them back. If the interest isn’t paid, the debt will not be serviced and you won’t be sent to collections. This lack of external accountability, a vacuum of required responsibility, is a driving force in the creation of this unpaid interest in many businesses.
“You don’t own a house, a house owns you.” You are beholden to the house to not only pay for it but to maintain it and even improve it. If you don’t then:
The bank will come looking for payments.
The counsel will get after you for dues.
The neighbors will complain at you for your unkempt yard.
Your insurance will get on you for not mending the damages.
With tech development there are similar, yet different driving forces.
The business will ask the development team to add features and reduce bugs.
The customers will ask the business to add features and reduce bugs.
The partner integrators will ask the business to add features and reduce bugs.
It is very unlikely that anyone will ask the development team to pay any of their time towards the technical interest payments if they don’t understand the mountain of pain that is coming for them.
Technical leaders must be accountable to themselves and the business to understand how large their line of credit is so that they can service it properly.
Interest re-payment is part of the total cost of ownership.
Several years ago I was tasked with architecting a new product(lets call it “MultiTower”). Our team, like many “start-ups” consisted of just a hand full of absolute rockstars. Over the next year we built our initial proof of concept into a viable sellable product. We picked up a couple customers and set about reducing bugs and adding features.
Our team now had a technical line of credit that we had to keep servicing. Every new feature increased the amount of ownership, and increased the amount of credit we’ve chosen to take out.
We kept up with frameworks, database engine versions, security patches and released often. I implemented a micro-service architecture and insisted on high standards for testing. 20% of our time was easily and without pushback spent on interest re-payment. We never backed down from our code coverage target or our automation. At the close of the second year of development we had a very well maintained application and no extra customers to show for it. The product just wasn’t something our customers wanted.
Developing the proper way isn’t going to get your startup off the ground.
“Well, Will,” you might say “thats why you should skip ‘proper’ and build a monolith at your startup - spend that 20% on your features!”
Developing in an expedient way isn’t what gets you off the ground either.
Servicing the interest on your technical line of credit is the best practice regardless of the architectural complexity.
How much money do you need to make a year to own a Ferrari? How about a private jet? How much time do you need to spend maintaining your Kubernetes cluster to keep the versions up to date and the plugin versions all compatible?
If you don’t have the resources for “fancy”, ignoring the maintenance to stretch your budget to afford “fancy” does instantly give you “fancy”. You won’t have that fancy thing, in a couth state, for very long if you don’t increase your budget for maintenance.
We were fortunate enough to have enough staffing, with the right levels of experience to support the repayment for our chosen level of complexity. “MultiTower” was created out of a established scaleup as a new product. We didn’t operate like a startup because we didn’t work at one. We had the benefit of successful, existing products to fund the work and an existing customer base to begin selling to.
There are a few inflection points on the way up. Especially within applications that have a “cold start” problem to overcome.
The things that make a startup successful are rarely the exact mechanisms that make them successful as a scale-up and are rarely, if ever, the correct path to creating a successful enterprise.1
The square of velocity is acceleration. The square of shortcut is debt.
A business that has reached its next stage of growth without planning for adaptation will continue to pile on unserviced debt to an ever growing line of credit. This will make new features harder to build, increase time to deployment, and frustrate the developers. The larger the unserviced debt the more time it will take to correctly bring new business decisions, features, and security fixes into production. EVERY change will take longer. This pressure on the development team has a tendency to force their hand to meet deadlines.
How are deadlines met under pressure? Shortcuts are taken. The more shortcuts that are taken, the more often that specific shortcut will effect a dependent system or feature. When shortcuts are taken, the metaphorical Interest Rate goes UP in addition to the expected increase in the size of the line of credit.
Why debt is good
Every shortcut you take
And bug you make
Every feature you break
Every step(function) you takeI'll be watching youAdds to your technical line of credit.
You’re going to be taking out this line of credit whether you want to or not.
Unfortunately the workload now exists. Having a business with a well serviced technical line of credit is incredibly attractive to your technical team.
Would you rather:
Pay the bill on a well maintained car doing preventative maintenance at predictable intervals
Be late to work cause it “suddenly” broke down and also have irregular maintenance bills that unexpectedly delay your journey
Treat your workloads the same way and give them the care they require.
Go ahead - Decide to build the monolith, or the micro service or the serverless or the IIS stack of your dreams.
Understand the line of credit you are taking out on behalf of your business.
Understand what the interest payments look like and service your technical line of credit accordingly.
Your investors, developers, and customers will thank you later.
Go read “The Cold Start Problem” by Andrew Chen if you’re interested in the best way to understand these inflection points and specific challenges to building a product that has a network effect. https://www.amazon.com/Cold-Start-Problem-Andrew-Chen/dp/0062969749 - side note - making this footnote made me realize that Substack doesn’t have the ability to make UNDERSCORE’d text(was trying to make a proper citiation). What a lean machine! Hopefully this feature is missing to make sure they have 20% of their time left to service the technical line of credit.