Yesterday I pointed out to the founder of the company that I work for, in the context of tech debt: "Well, since we moved the goalposts on that project, now we're out of 'credit card' tech debt and now in 'Adjustable Rate Mortgage' tech debt. Our goal should be to get to 'Fixed Rate Mortgage' debt." The problem is that too much tech debt can hold back feature development, or even materially impact hosting costs. In o…
There is two things to avoid: "overengineering" and "underengineering". The first case has happened when it later turns out that the developer did put in too much work into a feature than was necessary in retrospect, in the second case that they did put in too little work.
At the time of engineering it is usually not clear how much work would constitute over- or underengineering, as this depends on how much the feature gets to be used and evolved in the future.
But usually it makes sense to "err on the side of overengineering". Because (limited) overengineering merely means some development effort was wasted, while underengineering can easily mean years of painful tech debt that is an order of magnitude or two more expensive than the wasted effort from overengineering.
(It's similar to building a house. You usually want to make doubly sure you really do everything right or more than right, because if there are any flaws that turn up later, this often gets very expensive to rectify, sometimes so expensive that it isn't even worth fixing at all.)