You made a good argument that generalizing is an investment that often doesn't pay off.
That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with.
For example, if all your variable and function names are vague and misleading because you didn't take the time to choose names that make any sense, that saved you time now and will cost you later, but it has nothing to do with generalization.
> That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with.
That's one of the problems attributed to goldplating and over-engineering solutions. One man's future-proof implementation is another man's unnecessary indirection that's a problem to maintain. Thus we end up creating an environment where rigid implementations that are prone to colossal amounts of technical debt are preferred over adaptable solutions that minimize or eliminate technical debt.
That's a separate issue from technical debt because whether code is generalized is only one aspect of many that determines whether the code is a dream or a nightmare to work with.
For example, if all your variable and function names are vague and misleading because you didn't take the time to choose names that make any sense, that saved you time now and will cost you later, but it has nothing to do with generalization.