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.