[erhaetherth]

> Always write the simplest thing you can, but no simpler.

I don't think so. Time and time again the client will insist on stuff like "the customer only needs a single email address/phone number" but you're going to pay for that one later if you do the simple thing and add an "email" column.

Same for addresses.

And a whole bunch of other stuff...you need to normalize the heck out of your DB early on, even if you don't need it now. The code you can mostly make a mess of, just choose a good tech stack.

[amoe_]

> You're going to pay for that one later if you do the simple thing and add an "email" column

You'll only pay if the project survives long enough for that new requirement to actually surface, which often it won't.

[blowski]

Go down the simple path to start, and refactor to a more complex solution when it makes sense to do so. If experience tells you the client is definitely going to ask for it later, add a “break condition” that tells you when you need to upgrade. You can put entry points into the code - comments, interfaces - to make it easier to do the upgrade.

[izacus]

In many many cases this doesn't work and it crashes and burns the whole project/startup company when its necessary.

Sometimes messing up your fundamental architecture means that you hit a refactoring your company won't survive (while your competition grabs all the customers who wanted that feature your architecture doesn't allow).

This is where experienced lead engineers earn their worth - they understand which parts cannot be fudged and fixed later and need to be there from the get go.

[stef25]

Normalise the DB from the get go (doesn't really require much effort), then charge for the fact that "actually we have a customer who has 2 email addresses".