> The resulting big ball of mud (and subsequent performance problems of a long pipeline of relations) could be compiled away, resulting in a single artifact. S

> The resulting big ball of mud (and subsequent performance problems of a long pipeline of relations) could be compiled away, resulting in a single artifact. So..something like `git rebase` or `git merge` for both code and data. That actually sounds cool, but certainly not trivial. Part of why I've always liked git, despite its warts, is that it's a robust tool that has never crashed on me, probably due to the immense amount of man-hours that have gone into hardening it to be usable for the kernel. According to my Google eng friends, there's even crazier levels of VCS sophistication going on to make the Google monorepo work. How hard would it be to make something like that for data? Call me crazy, but I've found it generally harder or maybe just _higher risk_ to reason about data, because incorrect assumptions result in bad things happening -- heisenbugs or zombie bugs. Given that we're talking about data migrations...what happens when you have a merge conflict? That's the hard part. Fuzz testing and writing tests based on the final state of the system? Also hard, but will be hard no matter what because making sure the end state doesn't contain undesired corner side effects could end up being a combinatoric explosion that results in data corruption and an alarmed user (or more). > "just re-project your domain models based on the new flow of events" just re-project your domain models? Sounds like a migration to me. I get a little annoyed by abstract models in the subject article because they 1) re-imagine things that already exist and 2) focus on making the easy things easier and not on making the hard things possible. For example, I even see this in your reasoning, which I don't agree with. Time is already a first class concept in most software development models. If you're using an imperative programming language, sequence is the default. Likewise for most RDBMS migration frameworks I've used. It's the data migration that's the problem. It's applying temporal evolution to data in a structured, testable way that scales and doesn't decay which is challenging. I've been thinking about writing a data migration framework for a while -- something like `alembic` but expressly for migrating data and testing that the migrated data is sane. Thing is, that's hard, and it gets harder the larger your data gets in volume and heterogeneity. At a certain problem, it's 100% a question of how well your understand your data, your UX, your business logic, and the history of your data. In fact, the majority of places I've worked at suffer from the situation where an old, inactive customer has bad data that no one bothers to fix because it's a poor usage of resources for the business. New ideas of programming "styles" or "models" that don't emerge from these pains -- are they going to solve them? Maybe. But this one doesn't seem to do so.