Technical debt or mess ?

The other day, I had to work on a project, apparently having a technical debt, as said a developer who worked on it. When I opened it, I didn't see any technical debt, but rather a mess, only a mess. So let's be clear: a technical debt IS NOT a mess. A technical debt is a choice, a considered, reasoned decision, which allows you to do what you have to do quickly, but also constrains you to be as professional as you can be if you want to have a chance to solve this debt one day, and you will have to. Your code must be clean, commented, well-written. You have to test it, and you have to refactor it as much as you can. The mess? It's just a mess. Some low-quality and disorganized code, based on incompetence, or laziness and unprofessionalism.

A technical debt must be a business-driven decision in line with a long-term strategy, it should never be a developer's choice. The business is the only department which can judge that a version of a product has to be released early, involving a delay on the next version as the technical team will have to solve the debt before to develop others functionalities. The most important thing with a technical debt is that at the end, the business has to win. This is a business call, a well-considered decision by people who see the big picture, whereas a mess is nothing more than a mess, and always ends up to be a loss. A mess is always a loss. It is hard to read, hard to understand, hard to clean and has absolutely no chance of benefit in the future.

Don't be messy.

February 2, 2017
  • Technical Debt