Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

If you had a manager, a couple of levels above you, tell you that building software is like building a bridge, how would you respond to that?

If this manager truly believes that we should be able to accurately estimate and build a system, what good metaphors are out there to explain why this isn't the case?

share|improve this question

marked as duplicate by gnat, Robert Harvey, Jimmy Hoffa, Jalayn, kevin cline Apr 29 '13 at 18:36

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

8  
My friend's professor once asked his class what the difference was between building a software application and building a bridge; one of the answers was: You can't jump off software when you're done building it. –  paul Apr 29 '13 at 17:24
1  
It's hard to compete with one of a few celebrities among the programmers: even even after 30+ years Dijkstra's explanation is hard to beat. It's targeted at hardware designers, but bridge designs often fall into the same category. –  dasblinkenlight Apr 29 '13 at 17:25
4  
Engineering processes are not equivalent to manufacturing processes, so I disagree with the duplicate question suggestion. However, I do acknowledge the nuance between the two (eng vs mfg) processes may not be well understood. –  GlenH7 Apr 29 '13 at 17:31
3  
In software, often the objective is to sell the same thing multiple times (for major pieces, millions of times). If you sold the same bridge to different people, you usually get indicted for fraud.... –  Clockwork-Muse Apr 29 '13 at 18:12
3  
The difference is when a customer asks the bridge building manager to change the specs halfway through the project without taking more time or money, he has enough guts to say no. –  JeffO Apr 29 '13 at 18:40

6 Answers 6

up vote 14 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer
    
You don't have to be an engineer... popsicle stick bridge anyone? No? –  Jimmy Hoffa Apr 29 '13 at 17:22
    
@JimmyHoffa: Ok... what would be the popsicle-stick bridge analogue to software projects? One-off Perl scripts? ;) –  FrustratedWithFormsDesigner Apr 29 '13 at 17:24
1  
More likely all software engineering. They have about equal amounts of requirements ahead of time "Req1: Be like a bridge", "Req2: Made with whatever you can find for free (sound familiar?)" and are given the same timelines for completion ("Due next tuesday before story time").. –  Jimmy Hoffa Apr 29 '13 at 17:29
    
@JimmyHoffa: yeah... :( –  FrustratedWithFormsDesigner Apr 29 '13 at 18:56

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.

share|improve this answer
4  
Civil engineering projects often spend years planning prior to construction. –  Dan Pichelman Apr 29 '13 at 17:26
2  
Not only that, but plenty of times years of feasibility research will go into a project that will wind up not happening. In the software world, it's cheaper and easier to just build a failed project. –  Jonathan Rich Apr 29 '13 at 17:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.