Technical Austerity

I’ve been reading a lot of economics articles recently and have been thinking about our current debt crisis. From a Keynesian perspective, the government should be heavily investing anywhere it can to offset the lack of private investment. The politically popular austerity movements in Europe and the US argue that the fundamental problem is lack of savings, and that higher deficits will not raise short-term demand, but bring long term ruin to these economies. Macroeconomic policy is way to complex of a topic for me to comment on, but I can say a thing or two about Technical Debt and the investment parallel.

Technical Debt, unlike personal debt, is essentially something your organization owes its future self. Much like government savings bonds purchsed during WWII to finance infrastructure and military buildup, you promise your future self that you’ll do some amount of work in exchange for cutting a corner now. When you look at it not as something the developers are borrowing from someone else, but as something you’re borrowing from yourself, you have to weight it accordingly. There will always be hidden or unexpected costs for having taken the easy way out of some problem, but at least take the time to carefully consider the known problems you’ll likely face. So what happens when you’re faced with insurmountable debt?

The parallel for crushing personal debt is declaring bankruptcy, but is this the right approach? Bankruptcy, in this case, means a rewrite. Maybe not ground up, but it does mean you’ll face a lot of second system problems. Rewrites are so alluring to developers, managers and pretty much everyone. However, they also strand your current product in its current state. If you intend to keep updating the old product, while you build a new replacement, you’ll have to saddle a bunch of your developers, probably some of your best ones, with the enviable┬átask of maintaining a dying code base. One that you’ve decided is so bad that it’s unrecoverable and isn’t worth trying to fix. Truly, these engineers you’ve assigned this task will be grateful for the opportunity to “just keep the lights on” while other teams tackle building the replacement.

The other option is to hunker down and fix bugs. No new features until X bugs have been fixed. No more critical path bugs, no more middle of the night downtime, etc. Usually, management will declare this as the stated goal, and it sounds like such a miserable existence because it is. In the financial parallel, we think of it as the individual paying themselves out of debt month by month. In reality it’s more like a stagnant national economy which isn’t investing in itself. Remember, you owe yourself this time to do things right. Fixing bugs on an individual level isn’t the same as repaying your technical debt. Say you took a shortcut somewhere and built a quick version of a message system to keep two in-house systems in sync. In time, you needed to generalize it, but due to constraints you had to just copy/paste configuration files and code between projects without really abstracting things neatly.

Another aspect of long-term debt is that over time inflation rises can decrease the real burden of debt. If your one-off message bus turned out to be built for a feature users didn’t want in the end, it can die, and your debt is absolved painlessly. You saved the effort, accrued debt and over time, it became trivial that you had accumulated it. Technical debt matters most in high-interest scenarios, e.g. your core products and the libraries that comprise them.

What do you think, have you accumulated meaningful debt? Can you pay down your debt by dropping features that aren’t used or necessary? Or is it time to set aside resources and engineers for reinvestment to offset your debt?

This entry was posted in Technology. Bookmark the permalink.