Infrastructure Debt

I think the author has a different interpretation of "technical debt" than how it was originally intended.

Technical debt is not accidental and it doesn't consist of small mistakes, but it's due to a deliberate decision to cut corners when trying to get product or feature launched. Just like financial debt is not accidental, but a deliberate decision. (although you could argue that credit cards etc can create accidental debt too).

Idea is that it's okay and usually a good business decision to accumulate some technical debt to speed up your product development, but you need to keep eye on it and reduce it regularly, because if it grows too large, it can totally halt your product development.

I just changed job and got from a very unified setup (Linux-only, everyone working on one server) to a much more disperse one (all OSes, working on local). I agree that some diversity helps to keep flexibility and have a code base, data model that is more forgiving for little discrepancies.

But I guess there must be some checkpoints, or rules, were you don't allow any flexibility. You build a much more flexible project on rocks. For instance, no deployment if one test don't pass, and tests should include "X"-lint checks.

Author here:

With the understanding that I do most of my work in the most-bullied, down-trodden programming language here on Hacker News (PHP) I think that your choice of language, framework and persistence layer leads to technical debt or friction as raganwald commented above.

Like I said before, I view infrastructure debt as the cost of consistency in your environments and the cost of moving your code from one environment to another. Very rarely is the choice of language going to be a problem, unless you are trying to use a language in a way it's not intended to be uses (to throw out a completely random idea, like trying to use PHP as a functional language ).

Frameworks are a sore point for people, but mainly because they choose to fight them instead of trying to do everything the framework's way. Picking the wrong framework is a technical debt situation, not a problem of moving code from dev to production.

Persistence layer stuff is also a technical debt / friction issue. Chances are that you could use that particular data store without the persistence layer you chose. For example, I struggled to learn Doctrine1/2 but once I learned how DQL worked it became a lot easier to break out of the object-only contraints and create custom queries.

Hope that makes sense and answers your question.

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. :)

I liked the article because it made me think, again, about the debt we have at work. However, the few tacit solutions are not going to get me anywhere. This article needs a part 2 for debt that cannot be fixed with trivial solutions.