1. I'm confused about who the audience of this article is supposed to be. If you're a software development team that is not using version control in a fairly de

1. I'm confused about who the audience of this article is supposed to be. If you're a software development team that is not using version control in a fairly deep way, you're not "in technical debt" so much as "wasting someone's time and money with your monumental incompetence." I suppose it's still good to note that you should be using it, but you're not at the point of worrying about subtleties. 2. What the author calls "infrastructure debt" is just technical debt outside the application source code. 3. Technical debt doesn't (just) happen because people are lazy, or take shortcuts, or "plan to do it the right way later.". It happens because you generally don't start an engineering effort knowing everything relevant up front. Indeed, it's "engineerIng" precisely because you're learning important things and uncovering subtlety as you progress. Technical debt is the inevitable outcome of the fixed past rubbing up against the newly-discovered present or anticipated future. Update: So I guess I'm in the 'friction' analogy camp. :)