The bridge-building metaphor.

So much talk throughout the eons about how software development ought to be "like building bridges", and it turned out that perhaps it is far closer than we ever thought although not in the way we always intended:

Somewhere, someone's fist is pounding the table again. Why can't we build software the way we build bridges?

Well, maybe we already do.

As OSAF's programmers labored to construct their tower of code, piling bug fixes atop Python objects atop the data repository, I watched the work proceed on the new eastern span of the Bay Bridge. The project, replacing half of the 4.5-mile, double-decker bridge that several hundred thousand vehicles cross each day, was born in the 1990s and first budgeted at a little over a billion dollars. The original design called for a low-slung, unadorned causeway, but political rivalries and local pride led to the adoption of a more ambitious and unique design. The new span, a "self-anchored suspension bridge", would hang from a single tower. A web of cables would stretch down from that lone spire, underneath the roadway and back up to the tower top, in a picturesque array of gargantuan loops. It was going to be not only a beautiful bridge to look at but a conceptually daring bridge, a bootstrapped bridge —a self-referential bridge to warm Douglas Hofstadter's heart.

There was only one problem: Nothing like it had ever been built before. And nobody was eager to tackle it. When the State of California put it out to bid, the lone contractor to throw its hat in the ring came in much higher than expected.

In December 2004, California governor Arnold Scwarzenegger stepped in and suspended the project, declaring that the Bay Area region would have to should more of the ballooning cost of the project and calling for a second look at the bridge design. Never mind that work on half of the bridge, the water-hugging viaduct that would carry motorists for more than a mile on a slow climb up to the future main span, was already very far along, and every morning you could see vehicles swarming up a temporary ramp onto the new roadbed. Schwarzenegger wanted the project scaled back to a less novel and cheaper design. The governor, the state legislature, the state's transportation agency, and local governments spent months bickering and horse-trading. The transportation agency claimed that each day of delay was costing the state $400,000. Finally, in July 2005, a new compromise reaffirmed the fancier single-tower design, to be paid for with bridge toll hikes and other measures, and projected a new finish date for the bridge: 2012 —almost a quarter century after the Loma Prieta earthquake had shaken a chunk of the old bridge deck loose.

As I read about the controversy, I couldn't help thinking of all the software management manuals that used the rigorous procedures and time-tested standards of civil engineering as a cudgel to whack the fickle dreamers of the programming profession over the head. "Software development needs more discipline," they would say. "Nobody ever tried to change the design of a bridge after it was already half-built!"

(Rosenberg: pp. 346-347)

Sounds like a horror story. As a matter of fact, it doesn't sound as different from the story about the development of Chandler that Rosenberg narrates in his book: changes of heart, disputes, political controversy, worries about the final cost, delays... In other words, as soon as civil engineers try to build something that has never been done before —something truly innovative— they run into the very same problems software engineers do.

The physics of software.

Rosenberg brings up yet another interesting point when it comes to software development:

" 'Software engineering' is something of an oxymoron," L. Peter Deutsch, a software veteran who worked at the fabled Xerox Palo Alto Research Center in the seventies and eighties, has said. "It's very difficult to have real engineering before you have physics, and there isn't anything even close to a physics for software."

(Rosenberg: p. 276)

However, is it even possible to find out the "physics of software"? Is there one? The natural answer to that question is that, obviously, there is none. Software doesn't have a physical existence of any type whatsoever. It only exists in the form of bits and code and, prior to that, in a programmer's mind or, at the very best, some well documented specs. In that case, we could assume that Deutsch is right on the money: there is (and there will never be) any true software engineering discipline. And yet, is Deutsch's premise correct? Is it true that only physical things can be "engineered"? I suppose it all depends on the approach one takes to the issue. If we start from a mechanistic point of view, the assumption that only something physical can be engineered appears to be true. However, if we take a more systemic approach, it would appear as if everything is information, bits that flow around and can be channeled in one form or another. If his latter vision were true, then the problem is not so much that software engineering would be impossible but rather that we'd have to modify our own concept of what engineering means.