[Orou]

> always just about 'good enough' to solve the issue at hand

I've seen this approach really bite teams that only focus on the cost of implementing application behaviors rather than the long-term costs in terms of maintenance and systems complexity. If too many poor design decisions are made when a project is greenfield under the premise of "good enough" it can create technical debt so bad that the devs can't extricate the debt from core product features further down the line.

[berkes]

> this approach really bite teams

Me too. But that is typically a problem with how they define "good enough". And how that evolves over time. If "good enough" means "what we decided on 7 years ago" or "It works on my machine" then certainly that term is not covering what it seems to cover.

"Good enough" should, obviously, take future maintainability, security, new hires, evolving standards, moving business-cases and changing markets into consideration: i.e. overall complexity, reusability, consistency, maintainability etc.

Or, to put it differenty: if your "Definition of Done" is not evolving or changing over time you can be sure that the "quality" part in that DoD is sub-par in a few years and your project development will grind to halt somewhere in the next years surely. (edit: that, or it is so vague and up to intepretation that any new hire or insight can change it already. Which may be a good thing, IDK)