[Jtsummers]

> Another, more serious pitfall is the failure to consolidate. Although immature code may work fine and be completely acceptable to the customer, excess quantities will make a program unmasterable, leading to extreme specialization of programmers and finally an inflexible product. Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object- oriented or otherwise.

http://c2.com/doc/oopsla92.html

Technical debt is only "positive" in the sense that it may permit shipping something now or earlier, but it accumulates and becomes something that can slow the project team down to a crawl, or worse totally stall forward progress. In the end, unless your project can be thrown away, it's a negative.

[crdrost]

By the same token if you ignore all of the good parts about having a credit card, “in the end, unless your credit card can be thrown away, credit card debt is a negative.” There's a valid perspective for this but it's not a great one.

It's not just that it permits something now or earlier, but in shipping something now or earlier it can also increase the quality of what you are shipping. Ward saw it as the center of his preferred style of coordinated software development, XP. Sort of the old Daoist idea that the wheel needs the hole at its center, the negative enables the positive.