The reason is people don't want to specify the full set of requirements to that podcast app ahead of time. You can spend your year and $500,000 and then the users will play around with it for ten minutes and then tell you it needs to do this and that as well. And one of those features requires you to go back and make fundamental changes to your architecture making you redo a lot of your subsequent work, including a lot of the formal verification.

So it is harder because there is so much freedom in terms of what features a program can have and what the set of requirements can be. And that's just for getting to version 1.0. Software is expected to change much more than hardware is and if the requirements for version 1.7 can only be met by a severe change to the architecture or an ugly hack, the ugly hack will look very tempting.

Having said all that, I'm not sure I disagree all that much with you. A lot of this could be improved with more big E Engineering in the software world.

One way could be with some kind of professional engineer certification. It should be reasonably easy to get the first time by passing a test on some hard and concrete software engineering principles. But if you are ever found to break them, you lose the license and will have to go through a lot to get it back. That of course only works if companies care about people having this certification.

Which leads (as you mention) to government regulation. As someone who works with medical device software I can see that it actually works. The regulations succeed in forcing us to figure out a reasonably complete set of requirements early, but it is an ordeal. For a recent project we had working prototypes for basically all functionality and still we spent four calendar months doing nothing but requirements before we started developing the actual product.

And yet medical devices still have software bugs. There are 24 software related recalls in the FDA medical device recall database just this year so far: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfRes/res...