[tolmasky]

It makes sense why there's no software engineering then. If a requirement would be to have to learn about every software engineering disaster in the last 10 years, let alone the last 100 years, no one would have time to finish the course.

[mmastrac]

If we count disasters as those involving loss of life, I'm pretty sure we did learn about Therac-25 [1], one of Canada's major software disasters resulting in actual deaths.

[1] https://en.wikipedia.org/wiki/Therac-25

[BlargMcLarg]

Hardly.

We still treat documentation as a third class citizen.

We still allow stakeholders to pressure at the cost of long term security and sanity.

Important and rigid business rules, the most obvious candidates for automated tests, still go untested.

Access to critical parts is still open and backups are lacking. You can probably do a lot of damage without any malicious intent in many places if you're not careful.

I can go on. Funny thing is, these things still happen in companies which try to adhere to some kind of outside standard. Most CS classes talk about security vulnerabilities and cancelled software projects costing millions, but never go in depth. Even our research is lacking.

What we learned is no one cares until the costs are higher than the gains, excepting a few critical fields I'd wager 99% of software "engineers" will never step foot in.

[lambdasquirrel]

This. Management does not care. Does the market care? In spite of examples like the Therac disaster, the people in charge do not try to learn about what it'd take to make software more truly reliable.

In the early part of my career, I (and many of my friends) invested significant amounts of our time learning and pushing PL/T because the way things were going:

- Things are toys before they become tools. Early word processors were toys util they replaced typewriters.

- As the tools become more important, they will become more mainstream. Requirements will increase, e.g. that they be more reliable, that they become more usable.

- We now have designers in tech, indicating that the market cares about usability.

- There is still no formal verification of software, just "tests" which are applied in varying degrees of completeness.

To rely on "testing" is fine for a lot of consumer applications, but when I briefly worked in medical devices, we used C++. We did not hire a specialist with experience in Coq. Similarly when I worked with medical data.

I'll be quite blunt and cynical about it. Don't blame the software "engineers" / developers / whatever you want to call us. One of my friends actually went back to school to do research on this stuff, but I'm pretty sure he made a pittance compared to the friends who worked on the like button at Facebook. The market doesn't care. Call me a software designer if you like, I'll take the fat paycheck after spending the entire early part of my career trying to make things reliable, only to be slotted into the same "tech bro" category by a society that doesn't care.

[jrockway]

I think they meant that you learn about Therac-25 in school, not that we as a field learned the lessons.

It was an integer overflow. Those still happen all the time.

[dottedmag]

We even allow _some_ stakeholders to pressure at the expense of the rest of the stakeholders (e.g. general public, or even users of our software).

[chomp]

They did say major, not all engineering disasters.

At university, we were required to take a computer scientists & the society course, which software development disasters and ethics were the main part of the course. The Therac-25 case is a timeless classic, but there's others too. All software engineers should learn about past failures.

[bee_rider]

I don't think each civil engineer studies every bridge that's ever collapsed. Generally this sort of thing is handled by looking at case studies that represent particular failure modes.

[kube-system]

Engineering schools that have software programs do cover these topics.

[pdpi]

You don't need to know about every disaster, but even just the Therac-25, the Mars Climate Orbiter, or Knight Capital would cover a fairly wide variety of root causes and real-world consequences.

[minsight]

https://www.eng.mcmaster.ca/cas/programs/degree-options/beng...

[tenebrisalietum]

There's only a few root disasters, really. They are: C/C++, bash, ActiveX, COM, ACPI, and Javascript.