The article likens the building of a skyscraper to the <i>design</i> of software. I think that the analogy here may be wrong (having made the same incorrect analogy myself).<p>Perhaps the correct analogy is that the building of a skyscraper is akin to copying software (i.e., building a new replica of a design). In this regard software is the ultimate engineering. Once you have the blueprint (the final source code), stamping out copies is perfectly reproducible. The program applies to many more environments than a skyscraper design.<p>On the other hand, designing a skyscraper is alot like writing software. The designer doesn't know what the building will look like. There is an iterative process where ideas are thrown around, design errors identified and fixed, etc.<p>In terms of quality measurements, the same measurements don't apply to software since each copy is a perfect replica. There is little need to measure how closely a copy reproduces the design, it is often perfect. The design may have flaws, but so may a building design.<p>Having said this though, it sure seems that software is alot more unreliable than most bridges and buildings, so the question is, "Why?"
I'm done with these analogies. I find it a lot easier to make good decisions by asking direct questions about the situation I'm in and the outcomes I want.<p>edit: snark removal
See also <a href="http://www.codinghorror.com/blog/2008/11/tending-your-software-garden.html" rel="nofollow">http://www.codinghorror.com/blog/2008/11/tending-your-softwa...</a><p>The last line is a little presumptive for my taste. How do you know I didn't write the firmware for your pacemaker? There's gardened software and there's engineered software and both have their place.
Software is a lot more unreliable than bridges and buildings because it can be. People pay a lot of money to have reliable physical constructions. Some also pay for reliable virtual constructions (think 30-year-old space probes). There's no sensible business need for Facebook, say, to have three 9's reliability.