Technical Debt Leading to Technological Bankruptcy. Then Actual Bankruptcy. Cloud Computing Offers a Solution.

I figured I’d share part of an e-mail exchange this morning on the concept of “Technical Debt.” The term is well understood term in technology circles, poorly understood by investors, and totally ignored by accountants.  It explains a lot about winners and losers today.

Per the quote below, I wish this concept of “technical debt” actually sat on balance sheets. It is there regardless.

• Keeping your software running can be thought of as paying the interest charges on a credit card.
• Re-writing your software is paying down the actual principal amount you owe.
• Skimping on software maintenance and replacement balloons that technical debt balance.  But that is the next CEO’s problem (repeat that phrase a few times over several decades).
• Until the technical debt comes due.

This is a pretty clean way to understand a lot of older companies.  It is particularly applicable to Telecom companies worldwide.  They have 20-30 years of technical debt  coming due.  Millions of lines of rotten code in old billing systems, provisioning systems, and support systems.  Sitting on top of rotten copper in a non-data-friendly network architecture.  The telcos only paid interest and never paid down the principal.  So they are, technologically (and in some cases literally) bankrupt.

The article below is also an excellent explanation of why Public Cloud services can help minimize accumulation of technical debt.  Older companies with unpaid technical debt  balances will still have to pay them off – largely paying in to the Cloud.  Newer companies will use cloud to stay nimble.  Eventually killing off the old, encumbered behemoths.  That pattern will play out across a lot of industries over the next 20 years.

This dynamic is why AWS is going to be such a monster.  Hopefully one day Amazon does us all a favor and spins out AWS so we can invest in it directly.

https://techcrunch.com/2018/12/15/the-business-case-for-serverless/

“The problem with this approach comes back to an old axiom in software development: “code isn’t an asset—code is debt.” Code requires an entry on both sides of the accounting equation. It is an asset that enables companies to deliver value to the customer, but it also requires maintenance that has to be accounted for and distributed over time. All things equal, startups want the smallest codebase possible (provided, of course, that developers aren’t taking this too far and writing clever but unreadable code). Less code means less surface area to maintain, and also means less surface area for new engineers to grasp during ramp-up.

Herein lies the magic of using managed services. Startups get the beneficial use of the provider’s code as an asset without holding that code debt on their “technical balance sheet.” Instead, the code sits on the provider’s balance sheet, and the provider’s engineers are tasked with maintaining, improving, and documenting that code. In other words, startups get code that is self-maintaining, self-improving, and self-documenting—the equivalent of hiring a first-rate engineering team dedicated to a non-core part of the codebase—for free. Or, more accurately, at a predictable per-use cost. Contrast this with using a managed service like Cognito or Auth0. On day one, perhaps it doesn’t have all of the features on a startup’s wish list. The difference is that the provider has a team of engineers and product managers whose sole task is to ship improvements to this service day in and day out. Their exciting core product is another company’s would-be redheaded stepchild.

If there is a single unifying principle amongst a startup’s engineering team, it should be to write as little code—and be responsible for as few non-core services—as humanly possible. By adopting this philosophy, a startup can build a platform that can process billions of transactions at an extremely predictable, purely-variable cost with nearly zero devops oversight.”