Keeping Fun in the House

In the foreword to Structure and Interpretation of Computer Programs, Alan Perlis wrote something that has haunted every generation of programmers since: he believed it was extraordinarily important that we in computer science keep fun in computing. When it started out, he said, it was an awful lot of fun. We were responsible not for flawless perfection, but for stretching these machines, setting them off in new directions, and keeping fun in the house.

For a while, we did. And then — slowly, methodically, with the best of intentions — we buried it.

The Weight We Piled On

If you had shown a late-1990s programmer the modern software development lifecycle, they would have thought you were describing a bureaucracy, not a craft. In 1997, deploying an application meant FTP-ing files to a server, maybe restarting Apache, and refreshing your browser. It was immediate. It was tactile. You changed a thing, and you saw the result. There was a feedback loop measured in seconds, and it felt electric.

Fred Brooks, in his landmark 1986 paper No Silver Bullet, drew a distinction between the essential complexity of software — the irreducible difficulty of specification, design, and conceptual structure — and what he called accidental complexity: the difficulties we impose on ourselves through our tools, processes, and representations. He argued that the great leaps in productivity (high-level languages, time-sharing, unified environments) had all come from eliminating accidental complexity, and that the essential difficulty would remain.

What Brooks could not have predicted is that we would re-introduce accidental complexity on an industrial scale.

• Early 2000s — XML configuration files. Enterprise service buses. Application servers with 200-page manuals. J2EE deployment descriptors that were longer than the code they described.
• Late 2000s — CI/CD pipelines, dependency injection frameworks, ORM layers. Each one a reasonable idea that added another ring to the ceremony.
• 2010s — Containerization, orchestration, microservices, infrastructure-as-code. A hundred YAML files to deploy what used to be one binary on one server.
• Early 2020s — The average startup needed a dedicated platform team before it had product-market fit. The distance from idea to running software had never been greater.

Every layer was defensible in isolation. Containers solve real problems. CI pipelines prevent real disasters. Type systems catch real bugs. But stacked together, they built a tower of accidental complexity so tall that most developers spent the majority of their time on everything except the essential problem they set out to solve. We became, as Brooks feared, clerks rather than creators.

What the Late-'90s Programmer Knew

Picture a programmer in 1998. She has a text editor, a language runtime, and a loose idea. By lunchtime she has a working prototype. She can see the shape of the thing. She can play with it, push it, break it and rebuild it. The architecture emerges from the work, not from a three-week planning session.

That programmer lived inside what Perlis meant by fun: the direct, unmediated encounter with a problem and a machine. Not the absence of difficulty — difficulty is essential and welcome — but the absence of ceremony. The joy came from the ratio of creative thought to mechanical overhead, and in 1998, that ratio favored the creative side.

We told ourselves we traded that directness for reliability, scalability, and professionalism. And we did gain those things. But the cost was something harder to quantify: we lost the speed of thought. The gap between having an idea and seeing it exist in the world grew from seconds to days, sometimes weeks. And with that gap, something essential leaked out of the work.

Why LLMs Change the Equation

Here is what excites us: large language models are not a silver bullet — Brooks was right that no single innovation ever would be — but they are something he specifically hoped for. He wrote that the most promising attacks on essential complexity would come from tools that let great designers work at a higher level of abstraction, spending their time on the conceptual structure rather than on the mechanical expression of it.

That is exactly what is happening. And it is happening in the places where accidental complexity had done the most damage.

Revisiting Architecture

When you can describe a system's shape in natural language and get a working scaffold in minutes, architecture becomes exploratory again. You can try three approaches before committing to one. You can sketch a microservice boundary, see how it feels, throw it away, and try a monolith. The cost of experimentation drops toward zero, and that is where creative work thrives. Architecture stops being a document you write once and defend forever. It becomes a conversation you have continuously.

Automating Deployment

The late-'90s programmer's FTP deploy was simple because the infrastructure was simple. Today's infrastructure is genuinely more complex — that part is essential. But the YAML, the Dockerfiles, the Terraform modules, the Helm charts? That is accidental. An LLM that understands your intent and generates the deployment configuration collapses all that ceremony back down. You describe what you want running and where. The machine handles the translation. The feedback loop tightens again.

Testing with Intent

Testing is the most virtuous and the most tedious part of software development. It is Brooks's essential complexity made visible: you must think about every state, every edge, every failure. But writing the test harness, mocking the dependencies, wiring the fixtures? Accidental, all of it. When an LLM can generate comprehensive test suites from a description of behavior, the developer is free to focus on what should be true rather than how to assert it. That shift — from mechanical to conceptual — is precisely where the fun lives.

Not a Silver Bullet. A Return to Essence.

We want to be precise about what we are claiming. We are not saying LLMs solve the hard problems of software. The hard problems — understanding what to build, designing systems that evolve gracefully, reasoning about failure modes — remain irreducibly human. Brooks was right about that, and nothing has changed.

What has changed is the ratio. The proportion of time a developer spends on essential work versus accidental ceremony is shifting dramatically. And as that ratio changes, something else returns: the feeling that you are working with the machine rather than against it. The feeling Perlis described — the ability to see the machine as more than when you were first led up to it, and to make it more.

That is fun. Not trivial fun, not the dopamine hit of a clever hack, but the deep satisfaction of a mind fully engaged with a problem at the right level of abstraction. It is the feeling the late-'90s programmer had, restored not by going backward but by going forward.

"We're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun."

Your Architecture Is Your Org Chart (Whether You Like It or Not)

There is a deeper reason why software systems become joyless to work with, and Melvin Conway identified it in 1967: organizations that design systems are constrained to produce designs which are copies of the communication structures of those organizations. Fred Brooks later enshrined this observation in The Mythical Man-Month, giving it the name we know today — Conway's Law.

Think about what this means. If your company has seven teams arranged in silos, your system will have seven awkwardly coupled subsystems, regardless of what the whiteboard architecture says. If communication between teams is slow and formal, the interfaces between their components will be slow and formal too. The architecture doesn't emerge from the design document. It emerges from who talks to whom, and how easily.

Conway's Law is not a curiosity — it is the gravitational constant of software engineering. And for decades, it has been a source of enormous accidental complexity. Teams create boundaries that have nothing to do with the problem domain and everything to do with reporting lines and office politics. Systems calcify around organizational charts that were drawn for human-resources reasons, not engineering ones. The architecture becomes a fossil record of every reorg, every turf war, every hiring wave.

This is where the dream of harmonious architecture matters so much. Two thousand years ago, the Roman architect Vitruvius wrote that every structure must exhibit three qualities: firmitas, utilitas, venustas — strength, utility, and beauty. A building must stand up, must serve its purpose, and must delight the people who inhabit it. Remove any one of the three and you have a failure, no matter how impressive the other two.

Software architecture answers to the same triad. A system must be reliable (firmitas), it must solve the right problem (utilitas), and it must be a pleasure to work with and extend (venustas). That last quality — beauty, harmony, delight — is the one we most often sacrifice. We tell ourselves it's a luxury. But Vitruvius understood that beauty is not ornament. It is the sign that all the parts are in right proportion to one another and to the whole. A beautiful architecture is one where a new developer can look at the system and understand it, where the structure reveals the intent instead of hiding it. When we lose that, we lose the ability to reason about what we've built, and we lose the joy of building.

The Architecture Astronaut Problem

Joel Spolsky saw the pathology from a different angle. In his famous 2001 essay, he described what he called "Architecture Astronauts" — the kind of thinkers who float so far above the code that they lose contact with reality. They operate at such a high level of abstraction that their designs, however elegant on a whiteboard, don't actually mean anything in practice. They solve the template of a problem rather than the problem itself. They produce grand unified theories of everything while the team on the ground can't ship a feature.

Spolsky's critique stung because it was true. The architecture astronaut is the dark twin of the Vitruvian ideal. Where Vitruvius insists on the unity of structure, function, and beauty — all grounded in the reality of materials and human needs — the astronaut floats free of all three. They don't build; they describe. They don't test their ideas against reality because they've risen above the oxygen level where reality lives.

For years, the industry swung between two bad options: architecture astronauts who designed perfect systems on paper that nobody could implement, and exhausted teams who shipped code without any architecture at all because they couldn't afford the overhead. The first group produced beautiful diagrams and no software. The second group produced working software that became increasingly painful to maintain. Neither group was having fun.

Here is the thing that changes with LLMs and code working together: the cost of trying an architecture drops to near zero. You no longer have to choose between the astronaut's months-long design phase and the cowboy's no-design-at-all. You can describe an architectural idea in natural language, get a working implementation in minutes, run it, feel it, discover where it breaks, and iterate. The architecture astronaut's grand vision can be grounded immediately. Conway's Law can be challenged directly — if the tool doesn't care about your org chart, it can produce a system shaped by the problem domain instead of the reporting structure.

This is what Vitruvius would have wanted. Not architecture as theory, not architecture as bureaucracy, but architecture as a living practice where the designer works with the material, where the structure emerges from doing rather than from planning. Firmitas, utilitas, venustas — achieved not through months of deliberation but through rapid, joyful iteration with a machine that understands intent.

Why We're Chasing This

We built this company because we believe computing should feel like play — serious, demanding, absorbing play, the kind where hours vanish and you emerge having made something real. For too long, the industry treated that feeling as a luxury, something junior developers outgrow. We think it's the signal that you're doing meaningful work.

Perlis also warned us not to become missionaries, not to feel like Bible salesmen. We take that seriously. We are not here to preach the gospel of any particular technology. LLMs will evolve, change, perhaps be replaced by something we cannot yet imagine. What will not change is the underlying principle: tools should serve the creative mind, not the other way around.

Brooks framed the challenge as attacking accidental complexity wherever it hides. Conway showed us how organizations unconsciously inject that complexity into every system they touch. Vitruvius taught us that strength, utility, and beauty must live together or all three suffer. Spolsky warned us that architecture without grounding is just expensive daydreaming. And Perlis framed the purpose that holds it all together: keeping fun in the house.

We think these are all the same project, seen from different angles. Every layer of unnecessary ceremony we strip away is another moment returned to the work that matters, another moment where a developer gets to feel what that late-'90s programmer felt: the direct, electric encounter between a human mind and an interesting problem. Every architecture that can be tried in minutes instead of planned for months is another victory for venustas — for systems that are not just functional but genuinely beautiful to inhabit.

That is why we do this. That is what we are building toward. The fun was never gone. It was just buried under too many YAML files, too many org-chart-shaped architectures, too many astronauts who forgot to come back to Earth. We are digging it out.

---