Hmm - that's not good. That said, once I read the article title, my first thought was "Therac-25"? A quick skim before I read it confirmed that suspicion.
...and I have to add that I'm one of those "informally educated software engineers" - though I've never touched or worked on any kind of safety-critical systems (and I would decline such a position if offered, to be honest). I've been doing SWE for over 25 years now, and the only "formal schooling" I've had in the field was a couple of community college classes I took to learn C/C++ 2+ decades ago. Everything else has either been learned thru my employment, or at home. Prior to my first "professional" position in 1992, all I had was a high school degree and an associates from a trade school in "computer electronics".
But even I know about the Therac-25, and it's always in the back of my head.
The fairly recent change in the industry surrounding automated testing, test case programming, CI, etc - all of that which more or less fell out of the whole "agile" movement - has led to a vast improvement in software, imho. Yet bugs still persist, despite all of that and more.
We have to do better - I don't know how, or if it's even possible (from what I understand, it's not mathematically possible, except in maybe certain trivial examples, to validate all possible states of code - maybe I'm mistaken on that).
It's not about clickbait in this case. It's more like not giving away the answer to a puzzle. The puzzle itself is a good thing. It jigs us out of the mode in which we expect everything to be instantly explained. I can't prove it, but I believe that when operating in that mode, we are more likely to have predictable responses.
Also, there's a historical aspect to this. We don't need, and needn't presume, to rewrite the titles of classic articles.
I'm a firm believer in providing adequate and sufficient contex. Difficult enough given HN's 80 character subject field -- I've wordsmithed numerous submissions to fit. I've also stuck with numerous poor original titles with gritted teeth knowing HN's policies, sometimes addressing the ambiguity in a clarifying comment. And I've noted clickbait innumerous emails to HN, some of which you agree with, some not.
And yes, this is art not science: aimed at effect.
The Therac case study has acquired a recognition the contemporaneous article (and title) wouldn't have experienced -- the company name was then the more notable signifier. AECL has been far eclipsed by its most notorious product. Today, "Therac-25" should lead, on the same basis as "AECL" did in the original.
I'm generally a follower of Jacob Nielsen on microcontent:
Well-written, short text fragments presented out of supporting context can provide valuable information and nudge web users toward a desired action.
Mrtimer J. Adler does not fully condemn content concealment in book tables of contents, but his lips are clearly pursed, and nose wrinkled:
It used to be a common practice, especially in expository works ... to write very full tables of contents, with the chapters or parts broken down into many subtitles indicative of the topics covered. Milton, for example, wrote more or less lengthy headings, or "Arguments," as he called them, for each book of Paradise Lost. Gibbon published his Decline and Fall of the Roman Empire with an extensive analytical table of contents for each chapter. Such summaries are no longer common.... [P]ublishers have come to feel that a less revealing table of contents is more seductive than a completely frank and open one. Readers, they feel, will be attracted to a book with more or less mysterious chapter titles-they will want to read the book to find out what the chapters are about. Even so, a table of contents can be valuable.
-- How to Read a Book, p. 33.
The same argument applies to article titles at HN.
You've made the case (and commented on comunity failings) for defusing titles on hot-button subjects. That's valid.
This isn't that circumstance.
Pandering and information concealment as a deliberate policy, again not the case for the article as initially written, in the cotext of its time, is overtly manipulative, to no real gain.
...and I have to add that I'm one of those "informally educated software engineers" - though I've never touched or worked on any kind of safety-critical systems (and I would decline such a position if offered, to be honest). I've been doing SWE for over 25 years now, and the only "formal schooling" I've had in the field was a couple of community college classes I took to learn C/C++ 2+ decades ago. Everything else has either been learned thru my employment, or at home. Prior to my first "professional" position in 1992, all I had was a high school degree and an associates from a trade school in "computer electronics".
But even I know about the Therac-25, and it's always in the back of my head.
The fairly recent change in the industry surrounding automated testing, test case programming, CI, etc - all of that which more or less fell out of the whole "agile" movement - has led to a vast improvement in software, imho. Yet bugs still persist, despite all of that and more.
We have to do better - I don't know how, or if it's even possible (from what I understand, it's not mathematically possible, except in maybe certain trivial examples, to validate all possible states of code - maybe I'm mistaken on that).