Les makes some good points in his comparison of software with buildings and other complex activities here.

Comparing software development with the engineering of complex physical objects is always tricky, and fraught with risks. There are many similarities (they’re both hard to do well), but I think the differences are more profound than the similarities. Les appears to disagree with the current trend of TDD replacing static checking and formal methods as a means of ensuring software quality, drawing a parallel with bridge construction. Bridge construction is heavily rooted in engineering maths and physics – calculating the forces involved and the materials needed to withstand them, along with sample testing the individual components.

There are two major differences between bridge engineering and software development. First, the cost of testing. Unit tests are essentially free. They are generally run many times each day while development progresses, and act as a quantifiable measurement of progress, as well as a means of ensuring quality. The other major difference is in the economic breakdown. In a bridge, the design cost is probably less than 30% of the total cost, the rest being materials and construction. In a software system, probably over 90% of the cost is in the design (by which I mean the process by which source code gets written). Construction (ie. compilation) is basically free. There may be costs associated with deployment, but they are marginal compared to the design costs. In a continuous integration environment, deployment is often automated (the cost is then in the development of the automation), happening several times a day. Its a bit harder to construct and deploy a bridge that often.

All of which means that there is a definite benefit in spending time and effort (ie. money) in formally verifying your bridge design is correct, as the cost of having to rebuild a collapsed bridge is considerably more than the cost of fixing a broken software build. If construction and testing are more or less free, then using TDD and building as often as possible really is the most cost-effective means to develop a software system.