A long time ago, I studied research on what makes successful engineering teams. (Not programmers, other engineering fields). I don’t remember a lot of it, but one phrase stands out: “preserving ambiguity”. Successful teams don’t make decisions that aren’t needed, and they don’t get themselves locked in too early.
One fact about the beginning of a project is that you know less about the project than you ever will. And yet teams are often asked to provide estimates, do architecture, and make long-ranging plans at the beginning of the project when it is guaranteed that some of the assumptions will be wrong.
It’s a hard problem, but one way to get around it is to preserve ambiguity. Be humble, and try not to lock yourself into abstractions or structures before you know how the project is going to be used.
Which brings me to data models and specifically data validations, something I was thinking of as I was planning out the data model for my project tracker. Data validations are one way that you can lock yourself into assumptions about the data in ways that can cost you later.