ArticleS. MicahMartin.
BuildingaCity [add child]

Building a City


Building software is like building _____?


The common belief is that software is like engineering. Most people seem to think that building a software system is like building a bridge. This is likely the premise that Waterfall was built upon.

process Building a Bridge Building a Web App
Analysis: How Long?
What's it gonna hold?
What weather does it need to endure?
What's the feature set?
How many hits?
How much data?
What platform?
Design: Draw diagrams.
Do calculations.
Build miniature model and stick it a wind tunnel.
Think about high level architechture.
Draw class diagrams.
Draw some dynamic runtime diagrams.
Implementation Build the bridge. Write the code.

As an enlightened agilist, I know better than this. Building software isn't like building a bridge. But what is it like then? There is a craftsmanship movement that says software is a craft similar to woodworking or blacksmithing. I believe this is true. However, I can't say that building a software system is like building a wooden table or a chainmail shirt. Having built both a wooden table and chainmail shirt I can attest the the fact that these analogies don't capture the depth or complexity in software. So what does?

Cities! Building software is like building a city. No city starts with an analysis committee to decide how may people are going to live there. The population of a city changes over time. The infrastructure of cities is not designed before the city is built. A city's infrastructure starts simple and evolves over time as the city grows and changes. Cities are not built in one fell swoop. Cities start as small towns and are built up over time as new needs arise.

For those who have had the privilege, think about the first time you played SimCity. Do you remember the first time playing, just trying to figure out the rules. You probably started by building a small residential, commercial, and industrial zone along with a couple roads to connect them and a power plant. It wasn't long before these zones were fully populated at which point the citizens began to complain about crime. So you had to build a police station and add more building zones. Soon these were fully populated and the citizens complained about other problems. As the needs would arise you had to add a fire station, schools, libraries, and eventually, an airport, sports stadium, and the coveted Archology. That's how I started.

Although functional, my first city was eternally haunted by pollution, traffic, crime, poverty, and other normal city problems. This wasn't good enough. I wanted to build the perfect city; A city without all those normal city problems. So I pulled out a piece of paper and designed a city where the industrial zones where far from the residential zone. This avoided pollution. I drew an elegant highway system that was sure to avoid any form of traffic. The city layout was an even grid to evenly distribute police and fire station coverage. It was perfect! I started a new game to build my perfect city. In an hour I was bankrupt. I tried again, and again I went bankrupt. I must have tried a dozens times to build the perfect city and went bankrupt every time. Finally I gave up and reverted by to my very first approach..... start small and build as needed. This more agile approach seemed to work every time.

Building software is like building a city. Start small and go from there.




!commentForm
 Mon, 14 Mar 2005 20:19:23, Hui Deng,
Yeah, Anything complex will follow the same rule.
 Tue, 15 Mar 2005 00:02:08, Kelley Harris, Very nice analogy for software. Adds time dimension and more complexity
I like that the city analogy includes the time dimension, evolution, and enough complexity that most people would be struck by the limits of their ability to predict the future. Consider weaving in a comment about the cost of change curve.

Other analogies with time dimension:
* growing a company
* growing a garden
* developing a farm
* developing a network (or the internet)
 Tue, 15 Mar 2005 06:14:48, Denis Krukovsky,
My wife is an Architect. She's real Archirtect, she designs houses. She heard words like Analysis and Architecture from me and wondered why I'm professionally using words from her profession. Then she saw my diagrams, and she told me the same I just read.

Denis Krukovsky
<http://dotuseful.sourceforge.net/>
 Wed, 16 Mar 2005 00:16:42, Chris Noe, Deeper analogies
I like the city analogy. How about exploring this a little further by looking at specific activities in developing a software system. In the evolution of a city, what would be the analogies for:

prototyping
refactoring
debugging
performance tuning
configuration management
defining requirements
database conversion
archiving
involving stakeholders
federating with other systems
open source
continuous integration
backing out a deployment
the system has crashed

What city-building analogies might we learn from? Which things do we do better in software? What other software activities might have urban analogies??
 Wed, 16 Mar 2005 14:07:07, Joseph Graves, More analogies
The usual poor analogy I hear is "building a house" - I once had a contest to try to find 100 better analogies, but I must admit SimCity[?] is quite good. I personally liked Barbecue (as opposed to Ronco Sho-Time Rotisserie set it and forget it software development).
 Thu, 17 Mar 2005 14:40:18, MicahMartin, Deeper analogies explored
This is interesting....
  • Refactoring: - construction. Chicago suburbs are notoriously slow at refactoring.
  • Debugging: - This could be a lot of things... Why is Main street so congested? Why does Hinkston Park flood periodically? Why is there so much crime on the south side?
  • involving stakeholders: - democracy/voting
  • open source: - communes?
  • the system has crashed: - power failures, blizzards, hurricanes, ...
 Thu, 17 Mar 2005 19:56:19, Erik Meade,
That's pretty sweet.

It also helps to explain the tie in with <http://www.c2.com/cgi/wiki?ChristopherAlexander> the only "real" architect I have met said Christopher Alexander was not well recieved in his field.