[mmastrac]

There's something to be said about separating out engineering from development. As someone who went through the rigmarole of Canada's engineering test (though I never formally adopted the title of engineering because of the reporting requirements), there's something to be said of how considerate and thoughtful "engineering" is.

To become an engineer in Canada, you need to learn and commit to understanding in full every major engineering disaster in the country in the last 100 years, and how a failure in your duty as an engineer can actually kill people.

I feel like we could split software engineering from software development and gain a lot in our industry. Not all development needs to be engineering, but some absolutely does.

[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.

[liminalsunset]

Several potential problems:

1) You would have to pay these real engineers with licenses more for this to make sense. Currently most jobs that even make mention of this requirement pay well under what the software development equivalent would make

2) Companies don't like to hire "Real" engineers wherever possible because like all bureaucracy, sometimes they prevent projects moving forward. Companies are incentivized to employ the bare minimum of licensed individuals to sign off on the cheaper and faster work of the unlicensed proletariat. and pressure is put on the licensed to rubber stamp things.

3) I have found a lot of the courses in engineering school about ethics etc to be extremely rubber stamp/"mandatory safety training" ish, just like the dumb what's a stop sign test at the DMV. I doubt people en masse remember what they learn. I see it as a complex ruse to make people do the equivalent of sign a legal document saying "I accept the terms of this agreement and have the capacity to do so", more of "something that can be taken away if bad things happen" than "something to prevent bad things from happening"

[bee_rider]

> 1) You would have to pay these real engineers with licenses more for this to make sense. Currently most jobs that even make mention of this requirement pay well under what the software development equivalent would make

> 2) Companies don't like to hire "Real" engineers wherever possible because like all bureaucracy, sometimes they prevent projects moving forward. Companies are incentivized to employ the bare minimum of licensed individuals to sign off on the cheaper and faster work of the unlicensed proletariat. and pressure is put on the licensed to rubber stamp things.

These are reasons why companies might not want to hire engineers, but also reason why we might not want to do business with those sorts of companies. The fact that lots of companies seem to have gotten away with this stance seems to indicate a failure somewhere.

> 3) I have found a lot of the courses in engineering school about ethics etc to be extremely rubber stamp/"mandatory safety training" ish, just like the dumb what's a stop sign test at the DMV. I doubt people en masse remember what they learn. I see it as a complex ruse to make people do the equivalent of sign a legal document saying "I accept the terms of this agreement and have the capacity to do so", more of "something that can be taken away if bad things happen" than "something to prevent bad things from happening"

Yeah kinda. In defense of this sort of thing, going on to get a professional engineering license is definitely not something that all engineering students do. Many go on to do jobs that are more like programmers or technicians, right? Maybe the typical engineering degree should be renamed to pre-enginnering or something, but something tells me getting universities on board with that will be... challenging!

[sixstringtheory]

> commit to understanding ... how a failure in your duty as an engineer can actually kill people

I remember sitting in computational methods in uni while our professor was motivating the lesson on condition numbers, mentioning this is the kind of thing that can kill people, and students laughing at him.

Wish I could say that now that I've been in industry around a decade that the people around me have matured, but just as many still don't seem to care about quality.

Way too many people just chasing dollars and prestige with no appreciation for the power they wield.

[hutzlibu]

"there's something to be said of how considerate and thoughtful "engineering" is."

It is not just glueing things together and modify randomly until everything somewhat works under ideal conditions?