Technical debt is the cost a business incurs for prioritizing the present and ignoring the future. Everyone hates upgrading product versions. Even when the cost of upgraded software is covered by maintenance, upgrading has time and effort costs. It's often easy to rationalize deferring an upgrade by thinking you can take care of it later.

The problem with this thinking is that "later" often never comes until it's too late. And by then, the cost of resolving a crisis is far more than the cost of upgrading would have been.

Consider this fictional tale of woe. In the late 90s, Acme Services, (the same business with which Wile E Coyote traded), a local government service agency, bought an AVR Classic app from an up-and-coming local ISV software company. The product worked great and saved the company money and time. Recurring upgrades and fixes were included in the cost of the software.

Fast forward 15 years. Poor health forces the owner of the software company to close the business. His was a small shop and the business was quickly dissolved. Acme Services now faces a big problem. It has a minimal IT staff and no programmers. The ISV did all their necessary programming and upgrading.

Acme's options

Acme Services' options were:

  1. Hire someone to take over the ISV vendor's responsibilities.
  2. Replace the ISV software with a new package.
  3. Hire someone to write a new solution.
  4. Don't do anything and hope that the app continues to run without ongoing care and feeding.

After several few months of research, options 1, 2, and 3 were all deemed too expensive. Also, during these several months, the app continued to work just fine. Acme's principals said, "Hey, look, the app is still working, let's shelve any efforts to replace the software for now and revisit the issue sometime in the future."

For several years the app ran just fine. Acme needed new licenses a few times, but otherwise the app was essentially untouched since the ISV folded. Researching a replacement app was always on Acme's to-do list, but its priority was never very high. Day-to-day things always got higher priority.

After nearly a decade of running with no attention at all, Murphy struck and something nudged the server's disk arm enough to corrupt the database. Fortunately, Acme was diligent about backups. A few missing days of business needed to be re-entered, but otherwise the application worked again.

Lucky this time

Acme was lucky. Its business was on the abyss of collapse had that database not been backed up or its restore didn't work. This near-catastrophe is a tipping point for Acme. At some point, the substantial technical debt that Acme is accruing will come due.

Acme is now back to revaluating the same four options it had many years ago. What decision will Acme make this time? Its future depends on that decision.



Por favor, inicie sesión o cree una cuenta para enviar comentarios.