Why buildings aren't software: the modular fallacy

Every few years, someone reinvents the same idea: architecture should work like software. Modular, pluggable buildings, mass-produced and shipped anywhere, improved collaboratively and rolled out worldwide the way an open source project is. Shipping-container housing. WikiHouse. The pod.

It is an extremely seductive idea, and it is wrong, for a reason that has nothing to do with execution and everything to do with what buildings actually are.

Software is generic. Buildings are specific.

Well constructed software is universal. It can be duplicated a million times and behave the same everywhere: different machines, different operating systems, different users, all running identical code. This works because, for software, space is cheap and all distances are small. The operating system on the computer I’m typing this on ships with driver modules for enormous amounts of hardware I will never own, and that’s fine — unused modules just sit there, they don’t get in anyone’s way, they don’t cost anything to keep around.

A building can’t do that. Every building has to exist in one actual place, which is different from every other place. Distances inside a building, and between buildings, are not free: they cost people time, and they cost materials. A generic pod-room or pod-house is never quite the right size or the right shape for where it actually ends up, and that mismatch isn’t a bug to be fixed in the next release — it’s the permanent, structural cost of having made the thing generic in the first place. Efficiency in software comes from duplication; the space that duplicated code takes up is irrelevant. Efficiency in buildings comes from the opposite: from fitting as much utility as possible into the smallest footprint on one specific, immovable site. Modularity doesn’t help with that. It can only get in the way of it.

The caravan problem

Architects write enormous amounts about modular and pluggable buildings, almost all of it aimed at fantasy megastructures: renderings of stacked, plug-in towers that will never be built. What they conspicuously don’t do is look at the modular buildings that already exist and already work exactly as advertised — caravans, mobile homes, shipping-container conversions. A caravan is the pod dream, fully realised and mass-produced for seventy years. Its essential crappiness as a place to live is not an accident or a failure of design effort; it is the direct, unavoidable consequence of being modular. If architects looked squarely at the caravan, they would have to admit that the failure mode they keep proposing has already been tried, at scale, and the result is a caravan. So they don’t look. Real, existing modular buildings don’t photograph as “architecture” — a caravan park doesn’t have the minimalist detail, bold geometry and monumental scale that gets a rendering noticed — so the failure stays invisible, and the fantasy gets reinvented every few years by someone new.

Open source doesn’t fix it — it just relocates the problem

Projects like WikiHouse genuinely understand the open-source way: shared, collaboratively-improved designs, free for anyone to build. That’s a real virtue, and it’s one this whole project believes in too. But sharing a modular design doesn’t make the module fit any particular site any better, because the problem was never who owns the design — it was that the module is generic and the site isn’t. Committing to a fixed modular system, open source or not, is still a commitment to a fixed set of shapes and sizes, and every site that doesn’t match one of those shapes is stuck adapting itself to the module instead of the other way round. In software terms, this is exactly the thing open standards are supposed to prevent: architectural modularisation, even when the module itself is free and open, is still API lock-in.

Even the economics only work if you don’t have to live there

None of this is to say pods and modular systems have no advantages — they plainly have real ones. A stack of identical prefabricated pods is easier to manage, faster to build, and cheaper to finance than a set of custom-fitted buildings. Every advantage a spreadsheet can measure, the pod wins. The one thing it doesn’t do is make a good place to live, and that’s not a coincidence either: the qualities that make a building humane — daylight from more than one side, a shape that actually matches how a room gets used, a fit to the specific site and the specific household — are exactly the qualities that mass duplication has to sand away to make duplication possible at all. The efficiency is real. It’s just efficiency in the wrong currency.

What this rules in, not just what it rules out

None of this is an argument against learning from software. Software Design Patterns are one of the best things to come out of programming in the last forty years, and they trace directly back to the same Christopher Alexander who inspired this whole project. The reason they work in software and keep failing to transfer to buildings isn’t the idea of a pattern — it’s that software patterns are about how you wire things together behind the scenes, in a space that’s cheap and elastic, while a building pattern has to fight for a share of one finite, non-negotiable floor plan. That distinction is the actual lesson, and it points away from modularity rather than towards it: if a building has to be fitted, compromise by compromise, to one specific site and one specific set of needs, then the only design method that scales is one that can afford to do that fitting individually, every single time, for every single building. That’s what an evolutionary, pattern-language-guided design process is for — not because custom-fitting everything is quaint or artisanal, but because it’s the only approach that doesn’t have to lie about what a building actually is.

Rendered image of generated houses

Creative Commons License

Last updated 15 September 2026.