We’ve covered a lot of ground so far in this series on how we regulate cities. We started with why we regulate. We looked at things cities could stop doing (parking requirements, zoning, and setbacks). We considered the elements of the city, and why cities should treat streets and roads differently.

Today I’m going to sketch out a different approach for cities to regulating development itself — the actual buildings. I want to be clear up front, this is mostly a concept, and it hasn’t been fully tested. But I think there’s enough here to chew on, and I’d like to invite you all to help me refine and improve this idea.

Goals for a development code

Despite the fact that cities are vastly over-regulated today, I don’t think going straight to full libertarian lack of regulation is a realistic solution. We live in a democracy, people don’t like radical change, and the very firmly entrenched status quo bias is that nobody is allowed to build anything anywhere without clearing dozens of veto points. Many of our cities have tremendous pent-up demand, and we don’t have a culture of building beautiful places incrementally. If we went straight to full deregulation, I think we’d end up with a big wave of low-quality, disruptive projects. That kind of project can distort the market, and a big wave is likely to generate significant political backlash and pressure to revert the reform.

I think

It’s about re-acclimating our society to the idea that it’s good, normal, and healthy for the places we live to change over time. We need to embrace the idea that as the world changes, as our hopes and dreams and wants and needs shift over time, those changes become reflected in the built environment. The places we live need to be ongoing projects, not finished products.

How do we move from the status quo of stasis to a society where it’s good, normal, and healthy for places to change over time? At Strong Towns we’ve proposed the following:

The next increment of development should be allowed, by right, in every neighborhood in America.

What would it look like to have a development code designed to do that? If we unpack the goal a bit, we see our code would need to be:

• Incremental: This means that the code is anchored in existing conditions, while actually allowing economically useful change. We can’t define the next increment if the code doesn’t understand and relate to what’s on the ground today, but a code that only allows you to build more of what’s already there misses the whole point.

• Deterministic: aka “by right.” Today the majority of development is subject to some degree of discretionary approval and public input. But public input is broken. We need to move to a deterministic code that allows what it allows. If we aren’t happy with what comes out, we need to iterate on the code, not fall back to subjective, undemocratic vetocracy.

• Universal: we can’t just apply this approach as an overlay in some sacrificial district, it has to be the way things work across the entire jurisdiction.

Further, I’d argue that any code will be more successful if it is:

• Simple: the easier the code is to understand the easier it will be to adopt and enforce.

• Fast: we want our cities to be responsive to market conditions, that means most regulatory approvals need to be measured in hours or days, not months and years.

If we succeed at this, we’ll have created an Adaptive Code, a regulatory system that allows our cities to meaningfully change in response to market conditions, unleashing a transformative wave of incremental development.

The simplest Adaptive Code

To understand the concept I think it helps to start with a toy example, then think a bit about what the example is doing, and consider how we could build it up to something more useful. To that end, here’s the simplest Adaptive Code:

On any lot, you’re allowed to build a building one story higher than the building next door.

That’s it. Just take the existing conditions, and allow new development to go a bit further.

Of course this example is overly simple — what does “the building next door” even mean? Let’s iterate.

On any lot, you’re allowed to build a building one story higher than the rounded average of any adjacent properties.

So let’s say there’s a 2 story house on the left and a 1 story house on the right. The average is 1.5 stories, we can round up to two1. You can go one floor higher than that.

That’s not very precise about what “adjacent” means. We care about the lots next door, and the ones across from us, which share an interface:

On any lot, the adjacent properties are lots that front onto the same street and share a side property line, or are directly across from the subject property and the properties that share a side property line.

So now we have a set of 5 properties to care about.

Let’s go back to thinking about the next increment. Suppose our five neighbors are all one story homes, we get to build up to 2. If 3/5 neighbors are already two story, we could go to 3. This feels pretty good.

What about commercial buildings downtown? Let’s picture a vacant lot on Main Street surrounded by 2-3 story commercial buildings.

In this example the adjacent buildings are 3, 2, 3, 2 and 2 stories tall. The average is 2.4 stories. We round this to 2 stories, and we can go one higher than that, so the code says we can build three stories.

What if we feel that, going to 4 stories in this context would also be fine? We have to really think about how the next increment is defined. How about this:

On any lot, take the average height of adjacent properties in stories. You’re allowed to build 1.5x that height, rounded up.

Now we take our average height of 2.4 stories, multiply by 1.5, that gives us 3.6 stories allowed, which we round up to 4. So in our commercial example, we can now go to four stories.

How does that formula play out in our residential example? The average of the heights was 1.6 stories, multiply by 1.5 gives us 2.4, if we round up we get 3 stories allowed. Even if all the surrounding houses were two stories? We’d have an average of 2 stories, multiply by 1.5 and we still get exactly 3 stories allowed. Seems reasonable.

What if we’re happy with the incremental growth at the low end, but we’re in a major city where we want to be more permissive of taller buildings in our downtown area, where there’s already a mix of high rises? We divide the formula into tiers, for example set a multiplier of 1.5x for buildings under 5 stories tall, and bump it to 2x (or anything we want) after that. We could use even use multiple tiers if we felt we really needed to.

There isn’t a single right formula here, the point is the approach. Think about existing conditions, and think about how what the next reasonable economic increment would be. Express that progression as a formula, and test it against examples until we have something workable.

Parameterized vs Quantized

In these example we’ve only talked about building height. That’s the easiest increment of development to visualize, but there are other parameters we might care about, such as the floor area, lot size, lot coverage, etc.

To fully develop a code we’d need to decide which parameters we consider essential, then determine a governing function for each parameter. With that list of formulas in hand, we’d be able to calculate the size and shape of allowed building on any lot. We could call this the “parameterized” approach.

When I first started pondering this model circa 2010 I thought this parameterized approach was best, as it’s standardized and deterministic while simultaneously tailored to the immediate conditions around each lot. As a theoretical model that’s very appealing, essentially an algorithm to govern the evolution of each lot.

But as I’ve considered it over the years, I think there’s a simpler approach that might work better.

Instead of defining a governing function for each building parameter, we could quantize our development parameters into a series of steps — or, in urbanist terminology, define a transect of development types — and classify each lot with the closest matching level of development.

From there the rule could be very simple:

For any given lot, you may build to the average transect level of adjacent properties, or one level higher.

Let’s illustrate that with an example.

Applying the Transect

We could define our transect however we want, but let’s imagine starting with the “vanilla” transect from the Smart Code:

This transect describes six levels of development intensity from the “natural” areas outside the city all the way to the downtown urban core, giving each one a label from T1 to T6. For each lot in the city, we can compare the existing conditions to our transect and assign it the label that matches best.

We’d classify a house like this “T3.”

Whereas townhomes like this might be “T4.”

And per our rule, if you owned the ranch style house, you’d be allowed to redevelop it into townhomes.

Now remember, there’s not one single transect. If we feel like that example is too big of a leap, we could define a transect with smaller steps. Perhaps we could follow the beautiful missing middle transect developed by Opticos:

Different communities are free to define transects that fit the way they want to evolve. I would only caution that we can’t make the steps up in development too small, or else they’ll be uneconomical and won’t be built, meaning we’ll fail to unlock new housing supply.2

The quantized approach requires more work up front to define a transect and classify existing lots, but once that’s done it feels much more like conventional zoning. Every building would have a transect level, and we’d have a centralized definition of what development form was allowed at each transect level. The big difference is we’d be saying that every property has the right to redevelop to the next higher level.3

I think the similarity between a Quantized Adaptive Code and current zoning practice might make it easier to explain and administrate. On the other hand, the Parameterized approach of anchoring allowed development on the specific size and scale of the neighbors might sell better politically.

Relation to form-based code

In the last post I said it was important to regulate interfaces, but I haven’t expanded on that yet.

A second appeal of the Quantized approach is that can easily draw from the large body of existing form-based code. This model of Adaptive Code is not yet tested, but we have many form-based codes to draw from that havebeen deployed in real life. And while I see room for improvement, these codes mostly generate buildings with acceptable interfaces. This is great, because it means we’re close to good answers!

That said, there are two major flaws with the existing body of form-based code work that we must fix.

First, the simple thing: form-based code as practiced today still assumes land-use control. In fairness, the model Smart Code takes a light-handed approach, only restricting “lodging” and commercial development in the lowest intensity zones. But in practice, most form-based code gets adopted as design standards on top of fine-grained euclidean zoning. Either way, we don’t need zoning, and we should remove it from the code.

Second, the more difficult thing. In the model Smart Code there’s a provision called “succession,” which states:

Twenty years after the approval of a Regulating Plan, each Transect Zone, except the T1 Natural and T2 Rural Zones, shall be automatically rezoned to the successional (next higher) Transect Zone, unless denied in public hearing by the Legislative Body.

I’ve never seen this adopted in the wild, and it’s far too weak. Just as form-based codes today are generally embedded in the context of euclidean zoning, they implicitly assume stasis, building to a finished state. The most important thing a new generation of development codes can do is invert that paradigm.

Conclusion

In the past few posts I’ve offered a thesis on the role of the city, and today I’ll extend it:

Cities should plan roads, design streets, regulate interfaces, and embrace change.

We don’t need a centrally planned economy. We don’t need bureaucrats to paint a map that says who can do what and where. Instead, we need an algorithm for incremental growth that helps our cities rapidly respond to changes in market conditions — including infill, redevelopment, and horizontal expansion — while diffusing the impact of change throughout the city. The city’s job is not to micromanage the local economy, it’s to help the city mature and grow in the best and most broadly beneficial way.

Adaptive Code is rooted in understanding our cities as living, complex systems that naturally evolve over time. It embraces that change, and seeks to harness it for good.

I’ve been thinking about this since about 2010, but until now I’ve only shared this idea with close collaborators. In sharing it today, I want to invite you all to contemplate this with me and help me think it through. We can riff on it and refine it together, and explore the nuances and tradeoffs in future posts. I’ll look forward to discussing in the comments!