Here's my theory: we do know how to build very high quality software in a repeatable way. However very few organizations are willing to pay what it costs to do that, and that is why most software is so bad. Admittedly a lot of people writing code these days are "cowboys" (they don't care and neither do their clients, they just want speed) but that doesn't mean that the body of knowledge doesn't exist.
As we all know, something that works 95% of the time at 5% the price is very often better than a "perfect" solution. With critical systems like plane navigation, the tradeoff doesn't make sense, so you pay full price for near-perfection... your niche e-commerce site? 95% is sufficient.
I've done some software for buses, it's toy in comparison (with planes) but you get issues with noise, power supply, vibration, temperature, light (UV killing a touch screen) and probably lots more i've never encountered. The physical world can be every bit as unpredictable as the virtual one.
The only consistent thing you can state is that all these "real world" issues are to do with hardware whereas yours are more softwarey. However the consideration of such issues is necessary across the board.
"Essential complexity is caused by the problem to be solved, and nothing can remove it"
so the kind of complexity with have to tackle comes from the area of application we are in, not the programming task itself. its not about writing pretty, bugfree java code. let's assume your java is 100% perfect. there still remains the essential complexity of the problem.
now if the problem is in any way related to humans (a lot of software has to be 'a solution' for humans) then there is no way to proof a solution to be The Right One. hence B/B testing. this is at some stages the way to got.
show something & get feedback from the user, who knows more about the problem (himself) than you. this of course doesn't mean it's all blind trial&error - well in a way it is, but humans get better at that over time.
disclaimer: if you program the fuel-control for a rocket that is 30 years old, you can of course calculate the correct solution and resolve all essential complexity to mathematical formulas.
interestingly this was not the case for the first rocket-programmers, since the rockets kept changing every few month :)