Software engineering was taken more seriously 20 years ago than it is now. There have been some notable successes of rigorous development, but they're not well known. Here are two in wide use.
The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for some distance around if it doesn't follow the sharing rules for the air link, this is important to carriers. They got it right. Nobody talks about this much, but if that layer had problems, there would be regular cellular blackouts.
The second is the Windows Static Driver Verifier. This has been used since Windows 7. It verifies that kernel drivers don't crash, clobber memory or call the driver APIs incorrectly. Before the Static Driver Verifier, drivers accounted for more than half of Windows crashes. Now, crashes from signed drivers are very rare, and usually involve getting the driven device itself to do bad DMA operations. (IOMMUs are coming along to stop that.)
This shows the right direction for software engineering. Some software really matters, and has to be engineered properly. Most software doesn't matter all that much. Engineered systems should separate the two, develop them in different ways, assume the low-grade stuff will crash, and architect systems so the low-grade stuff can only do limited damage. We're seeing architectures like that in the mobile world and in server-side systems. In the mobile world, "apps" run in relatively contained environments. In the server world, things seem to be moving towards containerized "apps" in systems like Docker, running on some minimal glue layer inside a container running on a secure microkernel such as Xen and talking via message passing.
"The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for some distance around if it doesn't follow the sharing rules for the air link, this is important to carriers. They got it right. Nobody talks about this much, but if that layer had problems, there would be regular cellular blackouts."
That's... an interesting claim. You're basically saying that a cellular network is wide open to DOS attacks. I would need to see some serious proof before accepting such a claim.
GSM-type cellular uses time division multiplexing, with many handsets on the radio channel. Any handset which transmits during another handset's time slot will interfere with the other handset's signal.
Jamming is not a DoS attack. The essential feature of a DoS attack is that it forces the receiver to use resources, which it can then not attribute to legitimate users of the service. Jamming does not force a cell tower to use resources, hence it's not a DoS attack.
To put it another way, if jamming is a DoS attack, then so is hacking a server and reconfiguring its DNS. But we don't call that type of attack a DoS attack, we call it a penetration, or simply a hack.
And yes, wireless communications are susceptible to more physical attacks, such as jamming, but jamming is a) easy to track down, and hence dangerous to execute, b) expensive, you need to invest in special hardware to do it and c)surprisingly difficult to effectively execute in a radio environment like a cell network, which is generally quite adept at routing around things like jamming ( if you put your jammer between me and the antenna, my phone will in all likelihood simply find another antenna to connect to on the other side of me - with signal strength dropping as the square of the distance, your jammer is going to need to be BIG to jam me effectively).
The first is the operating system kernel in the air link processor of mobile phones. In most current phones, that's an L4 kernel with a full proof of correctness. Since any mobile phone can potentially knock out all phones for some distance around if it doesn't follow the sharing rules for the air link, this is important to carriers. They got it right. Nobody talks about this much, but if that layer had problems, there would be regular cellular blackouts.
The second is the Windows Static Driver Verifier. This has been used since Windows 7. It verifies that kernel drivers don't crash, clobber memory or call the driver APIs incorrectly. Before the Static Driver Verifier, drivers accounted for more than half of Windows crashes. Now, crashes from signed drivers are very rare, and usually involve getting the driven device itself to do bad DMA operations. (IOMMUs are coming along to stop that.)
This shows the right direction for software engineering. Some software really matters, and has to be engineered properly. Most software doesn't matter all that much. Engineered systems should separate the two, develop them in different ways, assume the low-grade stuff will crash, and architect systems so the low-grade stuff can only do limited damage. We're seeing architectures like that in the mobile world and in server-side systems. In the mobile world, "apps" run in relatively contained environments. In the server world, things seem to be moving towards containerized "apps" in systems like Docker, running on some minimal glue layer inside a container running on a secure microkernel such as Xen and talking via message passing.
That's software engineering.