When Technical Debt leads to bankruptcy

This post was originally published here.

One of my favorite technical metaphors is Technical Debt.  It’s easy to recognize a system that is collapsing under its own weight with Technical Debt.  Those are the ones that are pretty much impossible to change, and making even the most insignificant change requires levels of analysis many times more expensive than the effort to actually make the change.

I’ve seen a couple applications where Technical Debt increased to the point where no one could speak the name of the application without shouting expletives.  First it was a chuckle, but the chuckle turned sarcastic, then into a sneer, finally cursing and head shaking.

The mounting debt

Debt can build to a point before it needs to be addressed.  But as many new to credit cards can attest, ignoring the debt building up won’t make it go away.  In fact, those with large debts may spend most of their income on interest, unable to pay down the principal.  If these debts are ignored long enough and build up high enough, bankruptcy is the only solution.

Filing for bankruptcy

With enough Technical Debt built up, Technical Bankruptcy is the next step.  That’s when the cost of building a new solution is less than the cost of maintaining the existing application.  Developers file for bankruptcy by constantly complaining about the existing application and begging to do a re-write.  Once you decide to do a re-write, you’ve filed for Technical Bankruptcy.

Technical Bankruptcy gives developers a clean slate, but not in the eyes of the debtors (the ones signing the checks).  The business doesn’t want a rewrite every two years, but unless Technical Debt is paid off regularly, that’s what will continue to happen.  If rewrites keep occurring because Technical Debt is never addressed and is only allowed to build up, eventually the business will get wise and find someone else who can handle debt.

Keeping debts low

There’s really no such thing as “doing it right the first time”.  Debt is nearly impossible to avoid, and in some cases, unwise to avoid.  Sometimes incurring a debt is inevitable and advantageous, like purchasing a car or building credit.  But debt can only be reduced by paying off the principal.  All we can strive for is to keep as little Technical Debt around as possible, and pay it off as early and often as we can.  The answer to avoiding Technical Bankruptcy is not to avoid Technical Debt, but to pay it down through refactoring and continuous design.