This article addresses one problem with technical debt, the idea that one day the debt will "come due" and you'll have to fix some latent problem in a hurry and

This article addresses one problem with technical debt, the idea that one day the debt will "come due" and you'll have to fix some latent problem in a hurry and very painfully. While that can happen, a lot of the time you can carry the debt forward, as the article illustrates well. The bigger problem with technical debt is that it limits or slows your ability to do things. With real debt you have to make monthly payments and that reduces the total amount of cash you have to spend, which reduces your flexibility. With technical debt you "make a payment" whenever the speed you can make changes is reduced due to bad technical decisions of the past. For example, if you don't have tests then you can still change the code, but you have to spend a great deal longer doing manual testing. When the inevitable bug slips though, you have to spend the time to fix it. Since it's often not catastrophic, non-technical management will be willing to pay a known ongoing cost instead of an large, unknown one-time cost to remove the problem altogether. At my last job we were so mired in technical debt that progress had slowed to a near standstill. It was a 20-year-old codebase running on an IBM AS/400, mostly written in RPG (which is sort of like assembly language but for databases.) Field and table names were limited to 11 characters. When they migrated the product to the web, they kept the RPG code but added in a bunch of perl. When DB2 couldn't keep up, they started adding new data to MySQL. In all, there were 500 thousand lines of code in the system. Adding a field to the most important table was a 20 hour process, including a late night or two to issue some commands while the system was doing its nightly maintenance. There were five programmers while I was there, and the majority of our time was spend keeping the system going. There was never time allocated for cleaning up the existing system, so instead we'd just try and add features without making any schema changes (or adding fields in MySQL instead, as I mentioned before).