These are my thoughts after seeing Sarah Mei's thought provoking talk at Brighton Ruby—Liveable Code.

Sarah's talk explores why software has outlived the traditional engineering model.

A codebase isn't something we build anymore. It's a place where we live. Our goal isn't to finish it and move on. Our goal is to make it liveable. — Sarah Mei

The talk suggests that instead of a construction or architectural project, code bases might fit the model of an interior space occupied by people. Like a household with roommates where each person plays their part to take care of it.

For me, the talk title recalled the idea of the world's most liveable cities—a list Australians hear about at least once a year.

And so, I kept thinking of the analogy in terms of a whole city.

What do cities and software have in common?

Cities are complicated. They are shaped by the actions of many. But the actions of a few can have a big influence—for better or worse.

They evolve over time as needs change. They are never 'done'. And are never perfect.

They are made up of parts which are refactored. Buildings and roads are torn apart to make way for new ones. Some cities have fulfilled their purpose and are abandoned.

They can become so large that inhabitants will never understand the whole thing. People come and go yet it remains usable.

Every city is made up of the same ideas –– buildings, transport, rules, culture, ... –– these things are reimplemented across every city but each in its own way.

Sometimes the problems in a city aren't technical and have to be fixed by driving a change in its people.

They scale horizontally and vertically. Ok, I'll stop.

A few cities I have visited have specific parallels to software projects.

London

London is the successful legacy city. The people who started it are long gone. The roads are too small. When they were built no one envisaged the requirements we have today.

Its progress is driven by success and demand. It's built so fast that it's prone to cascading failure.

Bangkok

I noticed that the further you move away from the centre of Bangkok the nicer buildings look. The opposite to many other cities. As Bangkok grows new buildings are created but the old ones are not maintained.

Maybe you've worked on a project that always gets new features but never has time for maintenance.

Tokyo

Tokyo is big. It manages to handle an enormous amount of traffic. This sounds similar too The Recipe for the Worlds Largest Rails Monolith

Canberra

It's a greenfield city. A spot in the dust was chosen as the location of Australia's capital as a compromise between rivals Sydney and Melbourne. Canberra was built from the ground up when two teams couldn't agree to use something that already existed.

Have you ever worked on a project where an existing 'good enough' solution couldn't make everyone happy so the decision was to start something new?

Beltana

Beltana – a semi ghost town in outback Australia. About 12 people live there.

I was there with family who know some of the locals. They shared a story of a resident who wanted to build a fence around his property. He submitted a proposal to the Council. It went to an office in Adelaide (540 kilometres away).

A street in Beltana

The proposal for a backyard fence was accepted but with a condition—the corner had to be cut away because that spot was marked in plans for a traffic light.

Have you ever worked on a minor change in a small project that was impacted by future proofing?

Broken window theory

I'm not the first to compare a concept from city making to software. Broken window theory.

So what?

Sarah Mei is right, we are still experimenting with models to understand how to make software projects succeed.

Cities have their problems but are rarely thought of as being a failure. Why is that? Maybe we can learn a thing or two from the people who have been thinking about this for a while.

Here's a list to get started –– The 100 "Best" Books on City-Making Ever Written

If you liked this post tell me.