Log in

No account? Create an account
entries friends calendar profile Elf Sternberg's Pendorwright Projects Previous Previous Next Next
Software and Architecture are not friends - Elf M. Sternberg
Software and Architecture are not friends
There has been a resurrection of the old "We should make software develpment more like the traditional construction of houses and buildings. The architect delivers the plans to the construction company, which follows the instructions and delivers on the timetable specified." LaTeX guru Leslie Lamport has just such a piece in Wired this week, and it's a doozy.

The funny thing is, twelve years ago I worked for a company developing progress-and-safety software for... construction companies! The software was a distributed system for documenting the progress of construction and rapid disemmination of geotagged photographs to centralized distribution and organization centers that would disburse men and resources to various construction sites inside a given construction company's geographic area.

And here's the truth about construction: first, if there's a specification, it's entirely possible it's off-the-shelf. That means that there's no formal specification; instead, there's an ad-hoc specification generated in a Darwinian fashion based upon what has worked before. For most houses, warehouses, strip malls, and the like, there's a list of processes for surveying, laying foundation, building a framework, etc. The on-site foreman, much more than the specification, has the final say for what goes where.

A famous case of this was in the Guggenheim Museum, when the on-site foreman completely revised the scheduled of electrical outlets because he knew, based on experience, that the spec'd outlets were spaced too far apart to allow the cleaning crew to operate their vacuum cleaners and floor polishers correctly. That's the kind of experience that matters much more than specifications.

We're lucky if a "new and unique" architectural marvel resembles the artists' representations, but the underlying infrastructure often has little to do with the architect's vision. To the extent than a new construction technique is in use to support the roofs and walls, that often has little to do with how the toilets are plumbed or the outlets wired.

Software can be fragile-- a single segfault can bring a whole package down. A house can survive a percentage of bad nails, rotted beams, thin wiring; safety specifications demand that construction accommodate for these, because when a building falls over people die. Software has no such tolerances. You can build robust systems by making simple systems with intercommunications-- an entire revolution in that is going on right in front of Lamport. It's called Erlang, Haskell, NodeJS, AWS, the whole gamut of distributed architecture improvements.

Plus, I don't know a single decent software package that doesn't have specifications, doesn't involve thinking, doesn't involve design. Has Lamport (who I have enormous respect for in other contexts) actually been paying to the wholesale "the design of software and the software of design" discussion actually going on around him? Apparently not. Has he been paying attention to the emergence of Functional Programming and the strong separation-of-concerns debates? Distributed systems with their strongly spec'd and self-documenting RESTful interfaces have improved both the documentation and the robustness of modern code.

I could just as easily argue that "Software is like writing a book-- you write a first draft, then pare away everything until you have a glittering story that just works from start to finish." That's how Lamport's favorite piece of software-- LaTeX-- was written, after all.

Analogies are only vaguely useful in discussing the craft and discipline of software development. Lamport's analogy is more harmful than helpful.

I don't want to argue against specifications. I'm all for them. But software development itself is evolving at an astonishing rate while most houses are still built with wood and nails. I want readers to understand that if we built software the way we built houses, software's internals would be a collection of unreadable black boxes and knowledge of how to build software would became outdated even faster than it does already.

Current Mood: awake awake
Current Music: Boom Boom Satellites, Moment I Count

2 comments or Leave a comment
shockwave77598 From: shockwave77598 Date: January 25th, 2013 09:22 pm (UTC) (Link)
"if houses were built like computers, then the first woodpecker would have destroyed civilization."

Yes, but if houses were built like computers, you could save multiple copies of your house and have a brand new one just at the press of a button. Not to mention you could then move your house from one city to the next on a thumbdrive!

Talk about comparing apples and orangutangs.

The thing between the two is that in a house, there are many many ways of putting nails and lumber together. There are multiple redundancies and load paths instead of just one. Whereas in computers, there is usually only one program in one memory, and there is one single way for the program to operate correctly (but almost infinite ways the program / data can be wrong).
aprivatefox From: aprivatefox Date: January 26th, 2013 12:38 am (UTC) (Link)
and there is one single way for the program to operate correctly

I can see how this looks true, but it isn't. For any program of nontrivial complexity, there are myriad ways of implementing the solution. If there weren't, how would optimization be possible? There are better ways and worse ways, more maintainable ways and less maintainable ways, more efficient ways and less efficient ways, and ways that look right but turn out to be wrong.

In this regard, the metaphor comparing software to houses is apt; there's a lot going on behind that wall / interface, and you'd probably trust it less if you saw how it was put together.
2 comments or Leave a comment