We are not Building Bridges

Bridge by 96dpi, on Flickr

I gave my popular QA without QA talk at Nordic Testing Days 2013. When I finished my presentation, questions were raised that since no car manufacturer is doing Continuous Delivery or is pushing the tests to the developers, why should this technique be valid for software engineering?

I often hear this comparison between software engineering and civil engineering. Indeed, we can learn a lot from the art of building cars, bridges and buildings. However I find this analogy misleading.

We use similar terminologies like Design, Build, Architecture and many more. Yet the whole analogy to civil engineering is just wrong. We are not building bridges. We are building software.

In software, we can start by building a small house, then add ten additional floors, later add an underground parking, and eventually convert it to a skyscraper. You just cannot work this way in civil engineering. You would probably need to tear down the entire building every time you wanted to change its purpose.

The flexibility we have in software engineering is of a higher magnitude than any other engineering. Have a look at your latest project. It may have more moving parts than the International Space Station, and was probably built by a smaller team.

The error tolerance we have in software is also of a higher magnitude than in building bridges. Both should work as designed, and having your web site available for 99.9999% of the time is amazing. Having your bridge collapse for just 3.15 seconds a year (0.0001%) would be catastrophic.

Keep on learning from building bridges, but don’t tell me it’s the same.

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Buffer this page
  • Per Ullberg

    I think there’s a misconception about whats the product here. Consider a system that produces commercial newsletters and dispatches these to different lists of recipients. If we consider the product the service of sending newsletter and the system doing it is merely the support needed to do it in an efficient manner, then this is probably pretty close to what a car- or house- factory would be doing. The products here being houses, cars and newsletters.

    Now in order to produce our newsletters and stay ahead of the market with our services, we need the system built with certain properties. These properties are often described as nonfunctional requirements (another discussion probably). These properties would allow us to alter the system and conform to new market needs in an efficient enough manner to still make money.

    Just as car- and house- manufacturers of today design and architect their components like base plates, windows, electronics, factory lines, (even software) so that they may b produced efficiently and be used in a ton of different models.

    Just as our system can’t change the already sent newsletters the house manufacturer cannot change an already produced house. In a well architected system we could alter the output of coming newsletters just as well as the house manufacturer could probably add an additional floor and an underground parking to the future houses being produced.

    About those bridges, they could probably be viewed as critical components in a much larger infrastructure that would also include a lot of crappy road’s filled with potholes in between. Bridges do however close for maintenance and at times even collapse with deadly outcome. Space rockets (e.g. Ariadne 5) and x-ray machines (e.g. Therac-25) also do fail and kill people. So, just as bad bridges, bad software kills!


    • http://ToCodeIsHuman.com/ Uri Nativ

      Good points Pelle and thanks for the feedback.
      Indeed not all software products should be considered the same. A software of a life-saving-device might have tragic outcomes if something fails. Yet, I still think the flexibility of software is of higher magnitude than of physical products. In most software projects we work on, we can definitely take advantage of that, allowing us postpone some of the architecture and design decisions (even crucial ones) further down the road, and refine our decisions as we gain knowledge throughout the project.