Technical debt is a metaphor to describe the corners cut in technical work that may result it issues down the road. I find technical debt to be similar to having an old roof that is worn and tattered. It may make it a few more years or it may leak and ruin your walls and ceiling. Business very rarely understand these technical debts and don’t address them. When software is written their is almost always a deadline of an upcoming release. The business stakeholders will put pressure to meet this deadline and shortcuts will be taken that may lead to some future problems.
There can be many other causes of technical debt besides business pressures. We can have new developers that don’t understand all the ramifications of what the code they are changing or removing. I rarely see a code base that is well documented for the new developer. They come in and get to work on something and can’t quite be sure how things work. Some issues result because two or more parties fail to communicate or collaborate. If adequate requirements are not delivered to the software developer at the right time, it may result in a lot of re-work and missed deadlines. These issues also make software estimates so difficult to make. I have met some cagey veteran IT people who never want to give estimates, as they can always come back later to hurt you.
I have seen my share of software solutions that are very tightly coupled. This alone makes future enhancements very difficult. You build something in a brittle state and then try to add features and functionality on top of that is similar to playing the game Jenga, You keep pulling out pieces and sooner or later it topples over. Another important item is incomplete or nonexistent test suites, this is a very precarious situation as well. Any changes completed can be tested but can hardly be verified.