I think you're mainly looking at the failures that happened for mostly political or management reasons rather than where real attempts were made. Software engineering research gave us great stuff whose quality was largely unmatched by "programming, motherfucker" types who just threw shit together and hacked on top of it. Programmers making high quality stuff are rare. So much OpenBSD crowd differentiates based on how they apply a few proven methods to boost their quality. So, let's look at some that succeeded to see if software engineering had any value.

First was probably Dijkstra's THE operating system in 1968. Careful use of abstraction, interface checks, systematic testing of individual components, and careful composition led to a system that performed nearly flawlessly. All high assurance systems used a similar model in safety- and security-oriented systems with near flawless results despite much analysis, pentesting, field use, etc. Still same concepts used to this day same results. QED already. However, high assurance is just too limiting, slow-moving, and heavyweight in skill set. Best to focus it on premium components (eg TCB, key protocols). So, let's keep going to see what software engineering might have given average programmers.

By early 70's, Fagan at IBM implemented Inspection Process that formalized software review to try to counter all these bugs they caught. That it was systematic, regular, measured, and adaptive meant it caught tons of errors in the studies. Code reviews have only become popular among "programming, motherfucker" types in the recent decade with companies still trying to lure more in with HN articles despite it being empirically proven back in the 70's. Software engineering R&D also developed tons of tools to help but most programmers don't use them outside maybe testing or build systems.

Note: Around this time period, Wirth's languages and work built on them provide strong type safety, memory safety, interface checks, and one was immune to concurrency errors w/ language + architecture choices. Only a small niche adopted them and programmers were mostly not using them. All the buffer overflows, race conditions, etc followed logically.

By the 80's, Harlin Mills tried to stick it to hardware people by inventing the first, true engineering practice for software: Cleanroom methodology. Combined a formal notation, structured programming, decomposition, safe subset of language, by-eye verification conditions, usage-based testing, and statistical certification of quality. IBM tested it to find their defect rate was at shockingly low levels on first run with it improving from that point on. CASE tools were developed to semi-automate it. Small businesses differentiating on quality issued warranties (WTF!?) for their software at specific defect rates. Got mentioned on Dr Dobbs with a chance to reach programmers but "professional programmers" don't engineer software regardless of evidence. Cleanroom faded, typical programming continued, and basic defects are all over the place in software which is barely comprehensible.

From the 80's to now, research continued on building tools to automate as much as possible. Some prevented issues, some detected them during development, some caught them at runtime, some just recovered. In some situations, the whole problem could be solved via a synthesis and with reliable results. Programmers totally ignored this line of software engineering research. Unfamiliarity with languages like Wirth's, Ada, ML's, and Eiffel meant that would happen to a degree. However, programmers continued to ignore results even when applied to C, Java, etc that they used. A niche market of companies recognized the value and started applying such tools. CPU vendors, in EDA market, poured tons of money into it due to the cost of defects and got a series of incredible results going to this day. It's why hardware has a tiny defect rate despite tens of millions to ten billion logic functions running concurrenty.

Now, in recent events, some lessons of software engineering research and innovations have ended up in some mainstream stuff. Go, Rust, Scala, and Clojure come to mind immediately. The articles on them are pushing the stuff software engineers, especially in academia, had been pushing all along. Imagine how much better our code & tools would be had programmers listened to software engineers idk maybe 40 years ago.

Meanwhile, there's still companies and R&D leading the way. Altran/Praxis's Correct by Construction process has been in the lead with mathematical specs of behavior, proper error handling, SPARK implementations proven free of common bugs, and field results showing among lowest defect rate in existence. Galois is applying software engineering to low-level stuff combining Haskell, DSL's like Ivory, and C with good results. The Design-by-Contract crowd has been catching errors others missed. DO-178B scene is applying every tech and trick they can to reduce defect count. Embedded scene, like Esterel's SCADE, is generating whole apps from specs that work the first time. One academic combined Cleanroom and Python to get an amazing productivity-to-defect ratio. And so on and so forth with every independent evaluation and case study showing these methods deliver results "programming, motherfucker" types still believe don't exist. And predictably. And repeatedly. And even mathematically if you want. Kind of like engineering.

So, software engineering exists. The term got abused by the wrong types of people pushing the wrong stuff. The good stuff got ignored by them and most programmers. However, there's a string of tools, papers, companies, and so on applying that stuff. Their results are better than programmers almost every time sometimes with less work. Programmers are even adopting some of their stuff after decades of mocking or ignoring it. Those programmers own stuff is getting better. So, software engineering is a thing, it's contributions to our capabilities are enormous, and we'd all benefit if programmers used more of it.

My slogan: "Engineering, motherfuckers, do you speak it!?"

"No? We'll, that explains the results..."