[phendrenad2]

Ridiculous. Have you met engineers from other disciplines? They employ empiricism constantly. You can't build the golden gate bridge without proving that the steel you want to use can take the strain. "Obviously steel C is better than steel Y" won't cut it.

If anything, software development is sandcastle-building. We all have ideas on how to build it, but at the end of the day we're just amateurs fucking around with plastic shovels.

[kaba0]

Arguably, other disciplines doesn’t have to handle undecidable problems everywhere. Building a bridge can basically be “statically analyzed” completely, in that every requirement is known beforehand and there is a very constrained mutable state there. On the other hand, even the most basic program one can write will have properties not decidable without actually running the program. I would like to see much more rigorous testing/quality control in user-facing apps as well like websites, but lower level tools usually are written with much higher quality. You would be hard pressed to routinely find a bug in eg. the JVM — and writing formally verified programs is infeasible for any significant complexity.

[littlestymaar]

> Building a bridge can basically be “statically analyzed” completely

This. And even then, after the calculations are done the engineer add a “safety margin” (and it's not 10%, more like 500 or 1000%).

[kaba0]

Good point. And also, it is possible to add safety margins to other areas of engineering. One may be able to eg. store an array with padded nulls (actually we sort of do it at an OS level, just not with null but some “magic number”), but if it’s a loop/recursion, non-correct software will blow up either way - here it is more close to mathematics than science or engineering in my opinion.

[ncmncm]

We expect software to work, in places that are engineered. A SpaceX Falcon launch control system that encounters anything undecidable, whether in launch preparation or in flight, has utterly failed.

It was Microsoft that got people used to software failing on a routine basis, and "have you rebooted?". Before, anything that ever crashed, you sent back for a refund, or expected a tech to come out and fix it post-haste. Clearly MS could not make money that way, but getting people with no experience to believe failure was normal was quite cheap to arrange.

[samus]

You are comparing apples and oranges here. Bridge building should be compared to aerospace software engineering, not to the average CRUD app.

Apart from that, I think you are giving too much credit to construction engineering outside of the highly regulated sectors. They mess up just as often, and expensively so. But stakeholders in construction are slighly more aware that their requirements are going to be set in stone, pun fully intended.

What really makes a difference is the malleability of software. This is an invitation for feature creep and last-minute changes. Also, the impact of overengineered, unmaintainable software is not quite in-ya-face as for physical assets. Therefore, in software engineerin project managers need to be religious about these matters. And software engineers must get better at communicating about these concerns.