Technical Debt is defined as the eventual consequences of poor or evolving software architecture and software development within a codebase. Sometimes you have to pay it if you want that you can continue to maintain your application. But sometimes it is better to leave the situation unchanged as Ken Rubin wrote in his book.
“Sometimes technical debt should not be repaid. This is one area where the analogy with financial debt gets stretched. Typically the expectation is that all financial debt eventually will be repaid – although we know that isn’t always true! There are a number of scenarios under which technical debt should not be repaid. I will discuss three: product nearing end of life, throwaway prototype, and product built for a short life.
Product Nearing End of Life
If a product has accrued significant technical debt and it is approaching end of life, investing in any substantial debt repayment would be fiscally irresponsible. If the product is low value, we would likely retire the product (and therefore the debt) and devote our resources to higher-value products. If we have a high-value, high- technical debt product that is nearing end of life, it might make more sense to take on the high risk and high cost of developing a new product than to repay the technical debt in the old product.
Throwaway Prototype
There are times when deliberately taking on technical debt with absolutely no plan to ever repay it might be the most economically sensible thing to do. A common example would be the development of a throwaway prototype that is created for knowledge- acquisition purposes (Goldberg and Rubin 1995). The value of the prototype is not the code but rather the validated learning we get (Ries 2011). Because the prototype is not engineered for a life in the marketplace, it likely has some or a lot of technical debt. However, because it is a throwaway prototype, there is no reason to repay the debt. Of course, if we create a throwaway prototype and then decide not to throw it away, but instead treat it like an evolutionary prototype and evolve it into the product, we will almost certainly be starting with a foundation that is mired in significant technical debt.
Product Built for a Short Life
If we build a product for a very short production life, the economics might dictate that technical debt should not be repaid. […]Usually organizations don’t build products with an expected life of three months. Typically we are interested in engineering a product for an extended life in the marketplace.”
Source: Essential Scrum: A Practical Guide to the Most Popular Agile Process, Kenneth Rubin, Addison-Wesley, 500 pages, 978-0137043293
Image source: http://www.scrumalliance.org/community/articles/2006/july/technical-debt-and-design-death
I totally agree with this vision from Ken Rubin. We live in an imperfect software development world and this is what creates technical debt. With a long-term vision, you don’t want the technical debt to accumulate too much and you should take measures to reduce it. There are however a few cases where there is no common sense to clean a situation that is supposed to end quickly.
I would just be a little bit cautious about the first reason concerning the product nearing end of life. I have seen many “old” systems that were supposed to be near the end of life and that had a very long agony because product supposed to replace them never supplied the expected performance or because the project took much longer than anticipated.