I’d embrace the metaphor and simply point out where normal bridge building practices differ from normal software development practices.

The requirements of the bridge are defined well in advance and do not change during construction. No one thinks about moving the starting or ending point of the bridge midway through construction. No one expects a road bridge to magically support a train or to go from supporting a two lane rural road to an eight lane superhighway. It’s much easier to make accurate projections when you know in advance exactly what you’re being asked to project rather than making guesses and dealing with constant changes.

The vast majority of bridges are using extremely tried and true materials, architectures, and techniques. A Roman engineer could be transported two thousand years into the future and generally recognize what was going on at a modern construction site. There would be differences, of course, but you’re still building arches for load balancing, you’re still using many of the same materials, etc. Most software that is being built, on the other hand, involves lots of novelty. If you wanted a “standard” piece of software, you’d be buying it rather than building it so if you’ve made the choice to build something, that strongly implies that it is novel in some way. Novelty introduces risk but that novelty is also, presumably, what’s delivering value.

It’s also a bit of a myth that civil engineering projects are always accurately estimated. Most construction projects end up taking longer and costing more than the initial projections. The Big Dig in Boston, for example, was more than a decade over schedule and cost well more than twice the initial amount (more if you don’t adjust for inflation). And very, very few people that have ever built a house will tell you about how they were pleasantly surprised that everything was completed on time and on budget.

Essentially you’re asking what the difference is between an engineering process and a software development process. And there are a number of significant differences.

1. The top difference is the degree of constraints or requirements applied against the end product.

   • A bridge has fixed constraints. “The gap to bridge is ### meters wide.”
   • Software projects are notorious for the fluidity of their constraints. Last week passwords needed to be 4 characters long. This week it’s now 12.

2. The next difference is the body of knowledge surrounding the materials used to construct the end product.

   • Concrete, steel, and wood are all well researched and understood materials. An 18″ concrete slab reinforced with 3/4″ steel rebar at ### intervals will have distinct, fixed properties.
   • With software and because you happened to have just blinked, your preferred framework has a new major version released. The language you are using has introduced a new concept or programming approach. The properties of software tools are significantly more fluid.

3. Then consider the degree of specificity surrounding the requirements.

   • In addition to being fixed, the requirements are easier to dictate with an engineering process. The length of the bridge can be specified. The minimum tonnage it has to support can (and will!) be specified. These specifications have fixed, numeric values associated with them. Verification of the requirement is simpler to perform in the engineering process.
   • Now consider a software user interface and just how fluid the terminology is with specifying how it should look and feel and be “responsive.”

4. Next consider the repeatability of the process.

   • The carry-through knowledge of engineering processes is much higher than it is with software processes. By and large, building any given bridge is pretty dang similar to building any other bridge. It’s a pretty well fixed domain.
   • Software … not so much. While we have patterns to simplify and reduce the complexity of repeated tasks, patterns remain at a much more abstract level than what an engineering design process is.

5. Finally, consider the level of documentation and review.

   • Building a bridge requires an incredible number of blueprints, schematics, and associated drawings. Heck, there’s designs just to show specific elements (such as steel) for the structure.
   • When was the last time you saw that degree of documentation on a software product? If you ever have, it was a waterfall methodology which is often portrayed as “slow” and “unworkable.” How many times have your software design documents been reviewed by an external 3rd party prior to your beginning construction? How would you react towards having to wait on receiving a permit before you could begin coding?

There is value in the metaphor behind construction projects and software construction. But it’s important to not take that metaphor too far.

You asked specifically about estimating and building systems.

Estimation on the software side is more complicated due to the lack of specificity regarding the project. Lack of repeatability also also hampers the estimate because software projects are almost always the first time you’ve built something like that. Estimates on your first-of-that-kind project are always going to suffer a degree of error.

Build estimates suffer from the changing nature of the constraints / requirements. Because it’s apparently so easy to change software specifications, we fail to realize the impact of that change request. From an engineering perspective, software construction can tolerate an amazing degree of change requests and still survive. Not so with a traditional engineering project – you’d have to reject the change request or start the project over.

Build estimates also suffer from the changing nature of the body of knowledge. Constantly having to hunt down why XYZ feature isn’t working impedes development time and the ability to make accurate estimates. Concrete cures in a consistently predictable manner. Putting together a set of UI panels is nowhere near as predictable.

Disclaimers:

1. While I am an engineer, none of my response should be construed as a professional, engineering opinion.

2. While I work for an engineering firm, my comments do not necessarily represent those of my employer.

3. My background is in software development, not engineering process. Apply a healthy dose of skepticism and moderation to my comments regarding engineering process.

One of my teacher once talk about this, but the comparison was with a house. One of the main things that is different is the “invisible waste”. Now that I have almost 10 years in the software industry, I think it was the best argument ever!

For example, when you build a house, if you make a mistake or the requirements change in the building process, you will need to destroy a wall or even tear the house down. All the wasted material will be there, in a big pile.

In software, we do the same (sometimes) but there is no “pile of wasted material”. It’s invisible, and managers don’t care about invisible waste of money and time.

Since software is supposed to embrace change and that manager seems to know this (they always tell us that software is easy to change, so do it), this example show the difference between a bridge and a software.

There are a lot of ways they are the same: both are built to spec, not mass produced, both require a degree of planning, estimation, and technical expertise, and both require the application of simple principles on a larger scale. That makes the comparison more apt than, say, assembly line manufacturing.

To me, the biggest differences are the degree of precision required in software engineering, and how easy it is to change the finished product. That creates a vast difference in how design and implementation errors are accounted for.

As for precision, if a beam rated at 3 tons actually can only support 5999 pounds, your bridge will still stand. If you get one bit wrong out of gigabytes, it can bring an entire software application down. You can’t just make that bit twice as strong as necessary. It’s either right or wrong.

Fortunately, when that one incorrect bit is discovered, it is relatively easy to change. If you don’t discover a flaw in your bridge design until after it’s built, it can be extremely expensive to fix.

That’s what makes the processes so different. If you tested bridges the way you tested software, you would build it, then cause hurricanes, tsunamis, earthquakes, and extreme heat and cold to see if it still stands. After rebuilding it and retesting it several times, it would finally pass the tests, and you would start letting people drive on it. Then you would find out that blue cars cause the bridge to collapse, and you would rebuild it again. Then a customer would complain that the Golden Gate Bridge design doesn’t work when he tries to copy it for a bridge to Hawaii, and marketing would expect you to make it work for the same cost because to them it seems like the problem is exactly the same.

Requirements for a bridge are probably much less prone to changes from users. I imagine that unless it’s a very complex bridge, your users will want it to do the same thing, the whole way through the project.

I suppose that in some way, the more detailed requirements for a bridge could change (such as change to maximum load capacity, number of lanes and sidewalks, height of bridge, endpoints of bridge) but I would imagine that those some of those things are much harder to change after construction on a bridge has begun. And ultimately, a bridge is still a bridge – it gets you from one side of a geographic feature to another. I don’t think anyone would decide halfway through a bridge project that it should now be a radio tower or chicken farm.

Another thought: In software, competition with similar markets can drive timelines and requirements. I don’t usually see bridges built all right beside each other competing with each other for access (that and where I live they’re built by government agencies in charge of infrastructure).

Also: I don’t know how many bridges are given release dates and then told to stick with them. I’d like to think that a bridge won’t be open for traffic until it has been thoroughly tested so that it is known to not collapse when people use it. I wish the same could be said about software, but for most software (mission-critical systems excluded, of course) the cost in lives of “bugs” and defects is much lower.

Disclaimer: I’m not an engineer and I’ve never built a bridge

He is right, but not in the way he thinks. Do you know how much time and energy goes into planning a civil engineering project?

In contrast, most software engineering projects probably receive 1/10th the planning and are expected to be at least 50% more accurate.