I think technical debt falls into the category you describe, and I think businesses _are_ comfortable with technical debt; that's why it exists in every organiz

I think technical debt falls into the category you describe, and I think businesses _are_ comfortable with technical debt; that's why it exists in every organization. We can use the same terms we would use to define any standard debt you owe to a bank. Let's use "no documentation" as an example. The principal is the amount borrowed, or the time spent writing feature X instead of writing documentation. At some point you'll have to write that documentation, which would be your principal payment. And finally, the interest you're paying on that debt is the time developers have to spend figuring out something that could have been more readily available in documentation. > In a sense, debt is a good thing - you can timeshift revenue. Businesses are comfortable with debt. > But that's not what we're doing when we create technical "debt". I disagree. In the example above, there is plenty to be gained by establishing that debt. That new feature (or however that time was spent) might bring on more customers or generate more revenue, or influence more investment in the product, or whatever. My only wish is that technical debt were more easily measured; the net interest is highly unpredictable, and the overall monetary gain from establishing that debt is also hard to measure, which is why I might personally hesitate to call it a debt. Hopefully that made sense. Edit: Sorry I just realized you got like 20 similar responses. I had HN open for a few hours and when I sat back down I decided to respond.