"These are not the kinds of things the original article is directing your attention to. It's not talking about affine type systems and Hindley-Milner type inference. It's talking about management research masquerading as research on how to engineer software. And that's a fraud."

I totally agree with you there. I think a lot of the dispute in my post and yours centers on the definition of software engineering. You're applying it as the approach strictly about process, paperwork, drowning in numbers, etc with nothing produced. I'm applying it to mean any software development activities that apply engineering principles to software with engineering-like results. Computer Science is where a lot of what I'm citing came from, although CompSci != engineering software in general case. So, I have to have another term and "software engineer" literally means a person that engineers software.

Think I need a solution to this problem as it's recurring. I've clearly illustrated most programmers, even good ones, don't apply engineering fully and leverage what's proven. It's always a subset, if at all, often with informal approach driving the whole thing. There are groups doing the whole thing like engineering but they're rare & not paperwork pushers. If the phrase is irreparably tarnished, I might need to ditch "software engineer" for a phrase that describes the difference between how a group like Praxis does things and how a decent programming shop does it. The difference is how systematic it's designed, assured, and documented with every available, proven method put to use plus careful tradeoffs. Need a new terms I'm thinking because old one caused a huge chunk of your counter-points which apply to the crowd we both can't stand but not really the niche I'm promoting.

"Hardware has been able to take advantage of formal methods for much longer than software, because hardware has never been more than a thousandth as complex as software since at least the 1950s."

Partly and often developers are reason. Getting from hand-wired hardware to synthesis, formal methods, simulation, and testing took hundreds of millions in investment with many bright minds. The reason it worked was they noticed common patterns in their designs/implementations, started reusing them in new ones, built verification techniques for them, focused heavily on integration/reuse, and just went from there. Cleanroom was one of many methods that did something similar (but semi-formal) for software in structuring, verification, and integration. Formal verification teams did it again in so many isolated cases covering so many properties and types of software. The Cleanroom, FV, and model-based synthesis results show software development could get as much verification as hardware for sure. Just would take a sizeable labor investment in tooling and libraries plus agreement to simplify implementation and interfaces to facilitate analysis. Not saying that will mainstream but it's achievable and can be incremental. At least we're getting type systems and tooling, though, from the niche (esp CompSci) that cares about the stuff.

"btw, you misspelled "Harlan" as "Harlin"; the poor guy deserves better"

Damn haha. He really does. Yes, Harlan's methods could be improved. No argument here. An example was how the graph-based models were doing better than hierarchical. Another is executing your code to test assumptions on its dependencies. Point about Cleanroom was that it worked, its style/results were much like engineering, demonstrated many good practices, had empirical evidence backing it, and was a logical starting point that was entirely ignored by developers. And it wasn't the only one.

Far as FSM's: you nailed that one. Almost all high assurance systems used an Interacting State Machine model where FSM primitives were analysed and composed functionally (often CSP style). It was the only proven model in terms of getting results that survived all analysis and pen testing. You can do rigorous formal verification but that's high assurance: something you and other readers reject automatically in these discussions. So, I left that off.

Plenty of research & products working on different models but they're still getting proven out over time. Gotta use what's proven for now if I want get the best results.

"Formal verification comes from logicians and computer scientists"

All true and good examples: I listed some in another comment. Then they or the engineers I refer to put them into practice. Most developers don't. Still need a term for the former that won't tie into the other crowd you've been describing that stole and tarnished the phrase.