It's not only about cost to implement. There's also cost to change.
If your isolated module is bad, you can rewrite the code, keeping API the same. Cost to change is not high. You might introduce new bugs and that's about it.
Changing database structure might be hard. Adding new checks might require manual fixes to already bad data or multiple code paths for old and new data. Some migrations might require putting system offline. Often you can't just rollback your changes if things went wrong after few days.
Changing API with hundreds of customer... Good luck with that.
Changing POSIX API at this moment probably just not possible.
Whenever something is hard to change, quality requirements are naturally higher.
For data model quality requirements should be high. More time you spend, more time will be saved later. As we say: we're not so rich to buy cheap things. We're not so rich to afford poor DB schemas.
As usual, context matters and decontextualized discussions often devolve into people shouting past each other.
Sometimes you can't afford to do it right, quick and dirty is the way. Sometimes you can't afford not to do it right. It all depends heavily on how costs and payoffs are distributed socially and temporally.
The real trick is to be doing what fits your situation at the moment, and knowing how your situation might change over time.
It's not only about cost to implement. There's also cost to change.
If your isolated module is bad, you can rewrite the code, keeping API the same. Cost to change is not high. You might introduce new bugs and that's about it.
Changing database structure might be hard. Adding new checks might require manual fixes to already bad data or multiple code paths for old and new data. Some migrations might require putting system offline. Often you can't just rollback your changes if things went wrong after few days.
Changing API with hundreds of customer... Good luck with that.
Changing POSIX API at this moment probably just not possible.
Whenever something is hard to change, quality requirements are naturally higher.
For data model quality requirements should be high. More time you spend, more time will be saved later. As we say: we're not so rich to buy cheap things. We're not so rich to afford poor DB schemas.