The compact city and why we need new tools to build it
Software that evolves houses showed how a group of buildings can co-evolve on adjacent plots, each one forming part of the environment the others adapt to. That’s the compact city seen from a single plot outward. This article looks at the same problem from further back: at the street network the plots sit on, at how different building traditions solve the same problem in different ways, and at why the tools we already have — whether traditional urban planning or modern modular construction — aren’t built for any of it.
Res publica and res privata
Léon Krier drew a useful three-part diagram of what a town is actually made of: a res privata of ordinary, repeated, private buildings; a res publica of the comparatively rare public buildings — churches, markets, civic halls — that punctuate it; and the civitas, the two combined into a single urban fabric.
Figure: Léon Krier’s res privata, res publica, and the civitas they combine into
This project’s scope sits firmly in the res privata: ordinary domestic buildings, not masterplanning, not the public monuments, and not the streets and blocks themselves. Homemaker doesn’t arrange plots or lay out roads — every plot boundary is fixed and given, an input rather than something the software touches. That’s a real limitation, not a design choice made lightly, but it’s also not an accident: the rules that govern good streets and blocks are a different, already partly-understood problem, the one people like Alexander and Jane Jacobs have spent their careers on, and there’s no obvious case for a computational approach to that layer. What the software does need, though — and does have — is the ability to work with whatever plot shape it’s actually given. It fits non-rectangular plots as readily as rectangular ones, which turns out to be the critical property for working with the free-flowing plot boundaries of a real, historically-grown town, rather than only the rectangular ones a planner drew on graph paper.
Organic networks beat grids
The street network itself has a similar story. A while ago I experimented with evolving street layouts directly: starting from an arbitrary network where every junction has three connections (Alexander’s 50 T-JUNCTIONS), then using Dijkstra’s algorithm to compute travel distances between every pair of points, and letting evolution straighten the most heavily-travelled junctions into a T-shape, with the busiest route as the bar of the T and the quieter side street as its stem. The result is a network that minimises travel distance — and it ends up looking a lot like a traditional organic street network, not at all like a regular grid.
The obvious objection is that real streets serve more than one purpose, and minimising travel time is at best a partial account of what a street network is for. But the experiment wasn’t really trying to design a street network; it was trying to settle a narrower question. In the real world, hills, rivers, trees and coastlines are all it takes to force a regular grid to collapse into something organic — but what about a featureless plain, with none of that excuse available? Even there, an organic network still comes out ahead of a perfect grid on travel distance alone. It isn’t an elegant proof, but it’s a real one, and it means the case for organic street networks doesn’t depend on excusing them as merely following the terrain.
Small blocks
Block size on its own turns out to be one of the most legible predictors of whether a neighbourhood actually works. Looking at the variation of block sizes near where I live, all the liveliest, busiest parts of the area have a block size around 40 metres. Meanwhile a proposed ‘retail regeneration’ scheme for the city centre is doing the opposite of what the evidence says works — merging blocks together, with the biggest planned block coming in at around 200 metres. Nobody involved in planning that scheme appears to be learning from the parts of the city that already succeed.
Two form languages for one problem
Homemaker’s daylight-driven approach to arranging rooms reflects a specifically northern-European set of assumptions, and it’s worth being explicit about that rather than pretending it’s a universal law of good building. In the Islamic building tradition, privacy is the dominant concern rather than daylight — there’s no principle of right-to-light in Arabic building codes at all — so buildings tend to look inward rather than outward, and courtyard spaces do double duty as both amenity and circulation, connecting rooms the way a corridor would in a northern house.
The software wouldn’t need a different engine for this, just different settings and one genuinely unbuilt addition: the daylight requirement can already be turned down, and outdoor courtyard rooms can already be added into the same connectivity graph that gets checked for daylight, but the privacy/overlooking scoring module itself — the counterpart to the daylight code that would actually drive an Arab or Mediterranean form language rather than merely permit it — hasn’t been written yet. It’s a real gap, not a finished feature described in the passive voice: see Known limitations. Two form languages sharing one evolutionary engine is the plan; only one of them is actually scored today.
Besim Hakim’s work on historical Islamic building codes adds a sharper point to this. Hakim observed that these codes were proscriptive rather than prescriptive — they don’t hand you a recipe for building a house, they tell you when you’ve done it wrong. That’s exactly the logic of a pattern language rather than a form language, and it’s a useful reminder that this way of thinking about building wasn’t invented in California in the 1970s. It’s also worth knowing, if only as a corrective to how the word gets used in current arguments, that a large proportion of what gets called ‘sharia’ is what a modern reader would recognise as building regulations and planning guidance — and often good ones.
Why modular construction can’t do any of this
The modular fallacy already covers why mass-produced, pluggable buildings are the wrong tool at the scale of a single building: buildings are specific to a site, software is generic, and forcing a generic module onto a specific site always costs something. The same argument scales up. A modular system needs something regular to plug its modules into — at the very least, a grid of similarly-sized plots — and an organic street network with a real mix of block sizes and irregular, historically-accumulated plot boundaries simply doesn’t offer one. Pluggable buildings and organic cities aren’t a bad fit by coincidence; they’re structurally incompatible.
There’s a second, less obvious version of the same failure, which has nothing to do with construction technique at all. Buildings that look like they were designed with a spreadsheet usually were, and not by accident: an organisation that inhabits or commissions such a building typically is, functionally, a spreadsheet with people attached — so many people, therefore so much floor area, therefore so many identical floors. The resulting building falls directly out of that logic. A compact, organic city, built one plot at a time to fit whatever’s actually there, needs a different kind of client logic as much as it needs a different design method — which is one more reason this has to start from individual plots and self-builders rather than from institutions that already think in identical floors.
A vision thing
None of this adds up to a finished plan, more a description of what’s missing. Compact cities and towns. Walkable, which means compact buildings that fit even the smallest and most awkward leftover bits of ground. Streets where people can live without being terrorised by vehicles. Buildings that last for centuries, and that are adaptable enough to be worth maintaining that long — buildings where a wall can be moved, a window cut, a room subdivided or combined, as needs change. Cities that fit the landscape rather than the other way round: the world isn’t a sheet of graph paper waiting to be filled with identical cells, and identikit buildings can’t fit the world we actually have. Every corner, every room, every street tuned to be a place worth spending a life in.
That’s a world worth having, and the honest answer to how we get it is: start small, and work up. The technologies we already have are exactly the technologies suited to building the world we already have — mass-produced, generic, gridded — which is a way of saying our toolkit is too narrow for a different job. To build something different we need different tools, and since nobody else is going to build them for us, that means building them ourselves. Pattern languages are the basic technology underneath all of it; Homemaker is just one tool built on that foundation, one that happens to design house layouts, sunlight and daylight-sharing between neighbours. There’s plenty more still needed: tools for sharing construction information, for navigating bureaucracy and regulation, for financing buildings one at a time instead of a hundred at a time. None of this is the biggest or most important part of the job. It’s just the part on offer here.
© 2026 Bruno Postle (mail: bruno at postle dot net). This work is licensed under a Creative Commons Attribution 3.0 Unported License.
Last updated 15 September 2026.