I think analogies generally suck. Better to analyze things for what they are. Analogies are good for explaining difficult to understand concepts, but all to o

I think analogies generally suck. Better to analyze things for what they are. Analogies are good for explaining difficult to understand concepts, but all to often people say, x is analogous with y, y has something good/bad about it, therefore x has something good/bad about it. Technical debt is a good example of a bad analogy : 1. Assume some piece of code works, technical debt is only an issue if that code ever needs to be modified. Financial debt is always an issue regardless of what happens, even if you die. 2. Writing some code that generates the so called technical debt will often have an upfront cost saving, so whilst it might incur some extra work down the track, the extra work isn't a straight cost. The cost = (extra work - time saved up front). 3. Attempting to avoid technical debt often ends up with over-engineered code. 4. Being dogmatic and avoiding technical debt in all projects is often not good for the project / business / investors. Being early to market at the cost of code quality is often very important. I think point 3 is the worst scourge of all. It is quite common amongst mid-range developers. After working for a while they start to get good development skills and start to think too much, looking for ways to express their skills. In summary, it is like most things in life, there is a balance to be found.