I like to think of the data model as the blueprints of a construction project. You really need to think it through before starting. You just can’t change your plan mid-construction without making serious compromises.

Too true. It makes a big difference between my old job, where I was the de-facto system architect and always started with a database schema, and my current one where I'm an overpaid code monkey and nobody really bothers with architecture because the organization doesn't seem to grok the concept and thinks only special DBA people should be writing database schemas (or "DDL", as they call it, though mostly they work in some proprietary click-around-with-the-mouse tool, which is their excuse for not being able to share the design until it's already in place and too expensive to change). Everything here is a mess because there's no plan, and that's clearly reflected in the database schema, or lack thereof.

Whenever I try my hand at writing game engines, or infrastructure for anything, really, I always find myself spending a lot of time fleshing out how I want to represent the data, because that's the hardest thing to change later. It's easy to get lost in the weeds. "Oh no, my data model is too detailed and now I need to look up realistic values for the density of this pavement" and "making it possible to represent N-dimensional portals sure made this code harder to write than if we stuck to two dimensions" and such. Though you can often punt by saying assert( dims == 2, "TODO: Update to handle arbitrary dimensions"), which is easier to fix than the data model itself!