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.
🔥