Software Architecture Is Not Building Architecture

I have to agree with Worse Than Failure when they bash a commonly used Agile Programing analogy: The Goofus And Gallant Pyramids.


Two pyramid builders -- Goofushotep and Gallanthotep -- set out to construct a pyramid for their pharaoh. Being the traditionalist that he was, Goofushotep build the pyramid from the ground up and risked not finishing it before his pharaoh’s death. Gallanthotep, the Agile architect, built a small pyramid first and built additions sideways, so that there was minimal risk in having an unfinished pyramid when his pharaoh died.

This is supposed to illustrate how its better to not have a rigid plan when designing software. Don't have you goal be perfection: focus on always having something solid that delivers value. Of course, its a terrible analogy, and WTF called Agile a fad because of how rotten it was.

Now, I like Agile for some situations... But it really annoys me when people use analogies to compare building architecture and software architecture. Its like nails on a chalkboard, and makes me feel the need to rant. Since I'm a computer geek with a masters degree in civil engineering, I'm actually qualified to rant about this one!

So lets begin with the basics: Its a damn computer, not a dam! Buildings are required to have a sensible structure! There are innumerable rules and laws about their construction, which change every year. One must have extensive experience, qualifications and pass government mandated exams to design them... Whereas any yahoo with $50 can get a book and whip out a relatively useful web application.

Therein lies both the beauty, and the horror, of the modern software industry. You want software? Fine! Oh, you want it to actually work? That costs extra.

Here are a few reason why I think most "building architecture" analogies are misleading and false:

Its difficult to make a building cease to be a building

Short of dynamite or a wrecking ball, its pretty tough to crash a building. Imagine if you pushed the wrong buttons in an elevator, and the whole universe turned into the blue screen of death? Scary...

However, such a thing is all too common in programming. A few incorrect lines of code, and suddenly the entire system is worthless! Sometimes a junior engineer can track down the problem, but too often you need the original designer. That can sometimes be a massively painful ordeal...

Buildings always have a custom foundation

In a building, you have one solid piece of foundation that holds up the rest of the building. Every time you make a new building, you make a new foundation from scratch. You usually do this by mimicking other foundations that were used in other buildings, but your foundation is always custom.

In software, nobody has time for custom foundations! They take far too long to make, and very few people are qualified to design one from scratch. Thus, good computer applications are separated into layers: hardware, BIOS, operating system, drivers, network (with multiple layers itself), compiled languages, scripting languages, frameworks, libraries, data, and interfaces with other applications.

This fundamental lack of a coherent foundation means a lot of confusion about where one should start. Should we used a compiled language, or a scripted one? Do we need so much performance that we should worry about writing machine-language code? What framework should we use, and how much should we trust it?

Some say you should always start as high-level as possible so average programmers can quickly create useful applications with existing frameworks. Other point out that unless you know the fundamentals of what foundation that framework relies upon -- what assumptions it makes and why -- then you're setting yourself up for a big giant mess.

The truth is somewhere in the middle, but I lean towards the importance of the fundamentals.

Enabling communication between 2 buildings rarely causes their destruction

If I want to run a phone line between two buildings, everything is OK. We've barely changed the complexity of the design. However, if you want 2 computers to communicate, now you have to ask a whole lot of questions about security, spam, latency, timeouts, viruses, trojans, worms, etc.

In the past, they just ran some wires between computers and called it good. Unfortunately, now you've just vastly complicated the problem. If you were in academia in the late 1980s, you'll may remember how Robert Morris tried to warn people about this. Unfortunately, his warnings went unheeded until he released the Morris worm. Too bad for Morris he didn't double-check his code; instead of a proof-of-concept, he actually brought down a good chunk of the internet...

You can patch a building with very few side effects

Assume there's a hole in your wall. A little spackle here, maybe some tuck-pointing there, and its back to normal. It would be a mighty strange world if patching a hole in your wall caused your key to not fit in the front door... yet that happens in the world of software!

Quite frequently when you patch a software security hole, the system may begin to behave badly. Things that you used to do are suddenly blocked, or are very very annoying. Likewise, a patch level fix for one bug can cause other bugs to express themselves.

Conclusion

In closing, I hope people are more cautious with their software analogies... especially when it comes to design and architecture. Plumbing and waterworks design is a much better analogy, and not just because the internet is full of tubes:

  • The waterworks is a vast network of nodes, and connectors.
  • Congestion in one place can cause a cascade of errors elsewhere.
  • You can design a system that could deal with all possible traffic and disasters, but odds are that you have better uses for your money.
  • Small changes can be made by plumbers or junior engineers, whereas big changes must have central planning.
  • And finally, the network is so complex, there is no good way to design an entire system: you start with a template, modify it, and continuously test it with simulations until it suits the needs of all nodes in the network. Its one of the few areas of engineering that always requires an iterative solution, even for big changes.

So what do you think makes a good analogy? Which ones really get on your nerves?

comments

well

well sir i really got a gud piece of information from ur article. i got what i needed.

Recent comments