Composition to the Rescue
Typical software architecture is driven by absolutely terrible economic incentives to be the brittle mess it is today. There is another way.
Software's Original Sin
Every time I hand-roll another HTML form, I die a little inside.
Our industry's greatest moral failure isn't security breaches or privacy violations. It's that we've built a priesthood of programmers, hoarding the power of computing behind arcane incantations of JavaScript and Docker containers. We've chosen approaches that suit our highly trained elite rather than ones that democratize computing.
Where are all the bicycles for the mind?
We've known how to do better since the beginning. Excel turned millions of accountants into functional programmers. FileMaker let ordinary folks wield the power of relational databases. But instead of building on these successes, we've created systems so complex that even the priests struggle to maintain them.
Every business application today is essentially the same thing: small islands of simple code floating in a sea of state, connected by brittle ceremonies of data transformation. We pretend we're building grand computational cathedrals, but we're really just state farmers, tending our JSON and praying our API calls don't fail.
What if it all worked like FileMaker mashed with Excel?
What if every piece of software could be changed as easily as a spreadsheet? What if you could right-click anything - a chart, a form, a dashboard - see exactly how it was built, and change any part of it? What if "like that, but for my department" was three clicks instead of three weeks of development?
The Architecture of Liberation
The dirty secret of enterprise software is that most of it is just moving data around and occasionally showing it to humans. We dress it up with sophisticated terms like "microservices" and "event sourcing," but we're basically building ever more complex ways to fail at simple things.
I think this happens because the boundaries around shared work and ownership within a business just are at the wrong point for software. The vast majority of the software development effort into the world goes into idiosyncratic, short-term, business-driven dreck. Frest defines an architecture style that makes it natural to cooperate on a more optimal scale.
Our APIs are rigid contracts written in stone. Our security models are Byzantine mazes of permissions. Our user interfaces are change-resistant monuments to someone's best guess from six months ago. And God help you if you want to combine data from two different systems.
This isn't just inefficient - it's a fundamental betrayal of what computing should be.
Consider a typical "modern" business dashboard. Behind that seemingly simple chart lies a tangled web of API calls, data transformations, and hard-coded business rules. Want to see the same data slightly differently? That'll be a two-week sprint and three meetings with the architecture team.
Excel users are laughing at us. They've been doing ad-hoc data manipulation and visualization for decades. FileMaker users can build entire business applications in an afternoon. Meanwhile, we're writing boilerplate code to validate form inputs. Again.
The Revolution Will Be Composable
The solution isn't better frameworks or more sophisticated development tools. We don't need another way to generate CRUD apps or yet another JavaScript framework.
What we need is a fundamental rethinking of how software is composed.
Imagine a world where:
- Every piece of data has an address, but what you see at that address depends on who you are
- Everything you see always has a useful, relational, searchable UI
- Security isn't a bolt-on feature but emerges naturally from how things compose
- Functions are just relations waiting to be filled in
- Everything is a query, and every query can be changed
This isn't science fiction. The building blocks have existed since the 1970s. The relational model. Functional programming. Capability-based security. We just haven't put them together right.
The missing piece is a composition model that makes all of this natural and inevitable. A way to say "like that, but..." and have the system just understand.
The Path Forward
We've spent fifty years building software that serves the priesthood. Tools that make sense if you think in abstractions and can hold a mental model of asynchronous state mutations. Tools that actively resist modification by anyone without years of training.
It's time to burn the priesthood down.
The next generation of software won't be built on promises of scalability or developer ergonomics. It will be built on a radical premise: that everyone deserves tools they can understand and modify.
In the next post, I'll show you exactly how this works. How a simple idea about composing models leads to software that's naturally malleable, secure, and distributed. Software that normal humans can actually bend to their will.
The priests won't like it. But then, they never do.
Hear, hear, brother!
“Our APIs are rigid contracts… God help you if you want to combine data from two systems.”
Exactly. And this post hit so close to home I could barely sit still.
What you’re describing is exactly what we’ve implemented in a universal conceptual model: math, physics, chemistry, biology, econ, astronomy — all built out from shared declarative primitives.
🔗 CMCC GitHub Repo: Conceptual Model Completeness Conjecture ToE Meta-Model
https://github.com/eejai42/conceptual-model-completeness-conjecture-toe-meta-model
The core idea? A universal semantic substrate built from:
- Schema
- Data
- Lookups (parent refs)
- Aggregations
- Lambda Calculated Fields
…all in an ACID-consistent environment. That’s the whole stack — and it works. Every concept melts effortlessly under that model. (Don’t think so? Falsify it. 😏)
And yeah — the root problem is Syntax Locking. We try to encode high-dimensional concepts in 1D language strings, hard-coded into the perspective of one team, one language, one moment in time. And then we call that a “system of record.”
But if we just declare a Syntax-FREE Single Source of Truth, in an ACID model — say, in Postgres — we’ve defined WHAT needs to happen. That becomes a language independent, always machine readable and queriable live blueprint for all of the business rules. The runtime engine (Postgres, MySQL, SQL Server, whatever) can implement the “how.” But the semantic fidelity is preserved. Always.
This is the opposite of the 1D syntax trap. It’s composable, self-validating, and inherently snapshot-consistent.
It’s almost absurd we’re not doing this by default already. 🙄
🔥