18 Jun 2012. comments
In software development there is a concept of Technical Debt, a term coined by Ward Cunningham. The idea is that if you cut corners in the short term you are borrowing against the future maintainability of the software and that at some point, not unlike a credit card, you’ll need to pay down that debt by going back and fixing the hacky solutions that were put in place.
The eventual consequence of not paying down the technical debt is that the software will become harder to maintain, the architecture won’t evolve easily, and it makes it a lot harder to add new features and resolve bugs. If you take on too much technical debt and max out your borrowing limit, the software will rot and eventually fail (and get re-written).
Technical debt is a perfectly acceptable trade-off to make if it allows you to accomplish some time-sensitive goal like shipping your product before the other guy does. But the term has been abused over the years and often times carries different meaning to the average developer:
“Just do it quick and hacky for now and we will refactor it some day.”
This is dangerous thinking. Its dangerous because it represents the team lying to themselves. The problem is that the likelihood that a team will go back and actually keep their promise to refactor it later is slim. That quick hacky code tends to live on forever.