The technical debt ponzi scheme

Madoff would have been better off managing software projects than investing on Wall Street !

Whereas in finance, a Ponzi scheme is a sure road to jail, it seems to be the de-facto standard in software development.

A few months ago, I read Managing Software Debt, hoping to find methods about how to manage technical debt with some hard numbers (instead I found some good practices to avoid it, but that’s another story). At no place did I read that taking more debt to pay the interests of existing debt was a good practice though …

Thinking of it, I can remember of such Ponzi Schemes in nearly every organization I worked in. Here are a few typical manifestations I saw :

• writing bogus code to compensate for some other bogus code
• creating tools to workaround existing technical debt. Ex:
  • exotic build tools to build some code riddled with cyclic dependencies that no sane build tool can build
  • in house tools that do 10% of what standard (open source) tools can do on code following main standards

If this goes on for too long, you can end up in a technical debt death spiral : you know debt is out of control, so taking debt becomes the only way of actually getting anything done. “Let’s win this client now, because we won’t be able to later …”. It’s like running to one’s own ruin.

If your organization is in this stage, you might think at the ‘time horizon’ of your product, and discover that fixing the technical debt sometimes brings more value than getting this new client !

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!