For instance, stakeholders often demand that you cut corners to lower the cost of a project – deliver the same features for less money, or in less time. Or both.

As a developer, you may sense that this is a case of optimizing for the present at the expense of the future, but it can be very difficult to explain in a delicate negotiation where a large project or possibly your job hangs in the balance. In situations like this one, the concept of Technical Debt is a fantastic tool.   

Technical Debt, a phrase first coined by Ward Cunningham in 1992, is the idea that development shortcuts are a bit like making purchases with your credit card. As many college students discover, the more you believe that these transactions are free, the more devestatingly expensive they become. 

Eventually, Technical Debt must be repaid. If the debt is not repaid promptly, it will compound, and there will be crushing interest in the form of each change requiring substantial additional analysis and effort. 

When enough debt accumulates, there is a point of Technical Bankruptcy where the project becomes so difficult to maintain that it is less expensive to re-write it from scratch than to keep slogging along in slow motion.

And that's a bad situation because rewrites of large systems have a historical tendency towards disaster. That's why so many companies still maintain 20 year old lumbering mainframes. Believe me, it's not because they're passionate about Cobol.

One last thought on this: just as in business, sometimes accruing debt is the right thing to do - to meet a key deadline, for instance. But even then, always plan to go back and do another iteration as soon as possible.

clients, quality, design