Lambda the Ultimate

I recollect hearing two similar quotes. The first was about how "if planes were designed the way we build programs, flipping one little switch could make a wing fall off." This was usually made up on the spot, with variants about how flushing the toilet could force a nose dive, how one rivet removed in the tail fin could cause the landing gear to retract, etc. I don't remember some canonical, pithy quote...and my attempts to find one with search variations on "software programming 'wings falling off' " did not find a quote...but I remember this general idea.

The second quote is more pithy: "If houses were built the way software is built, the first termite would've destroyed civilization." No idea who is credited with this.

--Tim May

"If builders built building the way that programmers program programs, the first woodpecker to come along would destroy civiliization."

(I believe this quote is from Gerald Weinberg.)

It is indeed from Gerald Weinberg. I intended it asd a metaphor, not an analogy. I agree with those who say it's a poor metaphor. Programs have a far more arbitrary structure than civilizations, which is both fortunate and unfortunate. And, speaking of unfortunate, too much of the time, this arbitrariness is just that: unfortunate. For most programmers, a dose of restriction might be helpful. - Gerald M. Weinberg http://www.geraldmweinberg.com

Which is interesting, as this observation would seem to recommend something like the Law of Demeter to push these disparate systems farther apart, or stronger type systems and invariants to ensure correct usage.

I'd be wary of drawing any conclusions from such a terrible analogy. I've always found the comparing of software to essentially static structures like buildings and bridges to be worse than useless.

A better comparison, although still very imperfect, would be to devices with many moving parts, such as combustion engines or automobiles. (You know the original analogy is really bad when the dreaded car analogy is better.) That would at least capture some of the more problematic issues of dependencies between parts of a system. You can add rooms onto a house, and floors onto a building, and lanes onto a road or bridge, without necessarily having planned for it in advance. However, try finding someone to add cylinders to your car's existing engine. (OK, somewhere in Ventura CA there's probably a hotrod shop that'll do it, but you get my point.) And there are many single, small parts in a car that can break or be incorrectly installed, causing the car to entirely cease performing its primary function — very much the equivalent of the example of the flawed installation of a door handle in the basement.

Of course, people using unfavorable comparisons are usually doing it to bolster some point they want to make about the state of software development, often to promote a technique or sell a product. Software development is undoubtedly still pretty primitive in many respects, but such analogies may actually be damaging because of the erroneous beliefs and attitudes they foster.

You can add rooms onto a house, and floors onto a building, and lanes onto a road or bridge, without necessarily having planned for it in advance.

Same with some software, depending on the dynamism of the language (smalltalk for instance). Buildings, bridges and so on still have invariants that must be maintained in order for the structure to remain standing, and poorly designed software easily violates those invariants thus collapsing the structure, while well designed software does not, even when it is used or extended in unexpected ways. I think it's still an appropriate analogy given the right framing.

there are parts of a building or a bridge that you cannot replace willy-nilly, without causing the whole thing to collapse. Try removing the main cable from a suspension bridge.

Modern SW architecture isn't quite that bad. I can easily install or remove apps on my computer without causing the entire thing to crash; just as I can replace the doorknob on my bathroom door without the house falling down. Due to the nature of hostile attacks (which aren't constrained by spatial topology), more and more computer systems are being built with the software equivalent of bars in the windows and a good burglar alarm system; some go the full Fort Knox route. Online burlars and prowlers have more sophisticated tools then crowbars and slim-jims, after all. :)

Point taken. I think my problem with these analogies has a lot to do with the framing. The problem is that they tend to get remembered in isolation, and any framing gets lost.

Same with some software, depending on the dynamism of the language (smalltalk for instance).

It also depends on the nature of the program. It's easy to add web pages to a web application, but less easy to modify the behavior of the core back-end logic. Static structure analogies may hold reasonably well in some cases but require much more specific framing in others.

Programs are computationally more expressive than cars and bridges. To me this means that an analogy in this direction is just not possible. Wikipedia's distinction of analogies between logic/math and elsewhere seems to spot the error: cars & bridges may be more familiar (to most people), but they're not more complex (at least to us in the computational power sense - not the sheer detail sense).

Programs are computationally more expressive than cars and bridges.

I agree. I was going to say something about that too, but decided that I didn't want to have a discussion about considering a car as a particular type of computation constructed from physical parts. Or of dashboard computers and electronic car control systems.

To me this means that an analogy in this direction is just not possible

I wouldn't go so far as that. The analogy of, say, a blown gasket or snapped crankshaft on a car illustrates well enough, in a familiar way, the way in which an entire system can depend on the correct operation of a single part. For me, the existence of such an analogy makes it all the more egregious to use less apt analogies that imply that such situations are somehow amusingly unique to software.

That said, I'd like to grant Jerry Weinberg a pass on the woodpecker metaphor because (a) he posted a clarification here, which wins major points and (b) I'm a fan of his work, and want to know why I can't buy all his books in a (big) boxed set. :)

The analogy of, say, a blown gasket or snapped crankshaft on a car illustrates well enough, in a familiar way, the way in which an entire system can depend on the correct operation of a single part.

But nobody (even laymen) dispute this. And the analogy's target's been brought much closer to all things that have soft spots. To talk specifically about computers, we need a more complex target.

Even the original un-analogy seems to support this: there's no building where the roof can be brought down by installing a door handle. Somewhat like representing a proof of not A with A -> bottom, it seems to negate the hypothesis that buildings can be as computationally complex as software.

he posted a clarification here, which wins major points

Quite right. I also like his work. I am a fan of The Secrets of Consulting, but I guess no one will buy the book based on this endorsement, since nobody listens to my advice...

While comparing a software product to and engineering artifact is reasonable, comparing a software project to a machine is just bunk. More often than not, modules, classes and packages are spaces for people to work as well as parts of the machine. A software project is a little like a kitchen, with many cooks. How do we keep them from spoiling the broth?

The nice thing about kitchen analogies is that they give weight to process as well as design. A well run kitchen is a combination of workflow, layout, provisioning and a menu that's intended to be executed with the tools at hand. A car, on the other hand, does not have space for any workers in it -- nor does a finished house.