Hacker News new | ask | show | jobs
by chefandy 1383 days ago
Incorrect is a spectrum, and perfect is not-- there's a balance to be struck. In some projects, having a perfect data model would require having a perfect design, and I don't know if I've seen that happen once (for anything non-trivial) in my entire career. Depending on the environment and requirements, data model changes aren't even necessarily problematic, let alone catastrophic. You might not even know what your complete data model will look like until further along in the project. In other situations, having to make changes to some base layer of interface functionality could end up being the concrete shoes when it comes to developer time sinks.

The impulse to get the instant gratification of cracking into those first few lines of code should never supplant thoughtful design, but I've seen things go really wrong in the opposite direction, too. I reckon it's all about doing a good risk analysis, considering the costs of having to rework something down the road, and not letting your fear of getting that wrong stop progress longer than it needs to.

2 comments

When designing a complex system with multiple business modules and multiple services, correctness becomes a little more binary than that. Your data model tends to proliferate across anything that interacts with it - fixing it may require a complete refactor of all of those modules and all of those services. Throw in a process that is constrained by pesky things like needing to preserve WLB, limited surge capacity, and competing priorities, as well as varying levels of experience on your team, this rewrite can potentially take multiple years and require the maintenance of two parallel systems, and yet it must occur because the data model is foundational for everything else. Continuing to build on the wrong data model will keep boxing you in further until it's too late to ever fix it, with every new feature forcing you to fight with a fundamental flaw of your system. The resulting workarounds and hacks will slowly strangle your business logic until it's too complex to change with any confidence. It's kind of like building a house on top of quicksand.

When faced with such constraints, it's really, really important to get this right from the beginning.

Sure. I never said that data models needn't ever be perfect from the jump or that having a perfect design from the beginning would always be required. It really depends on the data complexity, structure, and how it's used. The important thing is to really think about it first.
I like this comment so much, I'm tempted to add a quote to the article