[fauigerzigerk]

The thing is, people have been building bridges for thousands of years. What a bridge is and what it does changes very slowly. Almost all the specialised knowledge that bridge builders have is about _how_ to build a good bridge.

Software is not like that. We may be experts in programming languages, algorithms and data structures, but the things we create and the problems we solve keep changing all the time.

We're not usually experts in these problem domains and in some cases there are no such experts at all. So our code needs to be a lot more descriptive and written for readers that may not be very familiar with the problem at hand.

We are more like lawyers supporting law makers or even like law makers themselves.

[falcolas]

We think bridges are a very well explored domain. Then something like the Tacoma Narrows incident happens, and we realize how much of a fallacy that really is.

Bridges are unique to their locations and their scale: what works over a creek will not work over a ravine. What works for a pedestrian will not work for a car. What works for a car will not work for a train. What works for a train will not work for a marching army.

[fauigerzigerk]

The Tacoma bridge collapse has a wikipedia entry exactly because bridge building is a very well explored problem and bridges don't usually collapse.

I don't doubt that each bridge comes with unique challenges. But the purpose, user interface and constraints of bridges have remained stable enough for long enough to allow specialisation. That is not the case in many areas of software development.