In software development, there is a concept of ‘Technical Debt’. The original term was coined by Ward Cunningham, and the idea is that if you cut corners in the short term, you’re borrowing against the future maintainability of the software and that at some point, not unlike a credit card, you’ll pay down that debt by going back and fixing the hacky solutions that were put in place.

“Just do it quickly, we’ll refactor it later”

The problem is that the likelihood that a team will go back and actually keep their promise to refactor it later, is slim. When the realities of development pressures and deadlines come in to play, the time (and ability to remember) to go back and refactor is destroyed.

The eventual consequence of not paying down the technical debt is that the software will become harder to maintain, the architecture (or lack of) 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.

Now, I think there is a balance to be drawn; Sometimes you do want to put a solution in place with the intent to refactor it later. Business pressures and management decisions can cause you to focus on the short term wins of getting a solution out quickly, and that’s a reality that you’ve got to be prepared to deal with. The difficulty lays with being disciplined enough to go back and keep your promise to improve and iterate. In my experience though, taking on technical debt will almost always make you lose time in the long run. This is not something specific to software development, and there are parallels to cutting corners in other lines of work.