Hacker News Reader

I took an Ethics for Engineers course as an elective in college (sometime during the stone age). Wrote a paper on Therac-25. Had I not, I may not even been cognizant of the risk involved.

A single week lecture on this topic could move the needle.

Or regulators like FDA could demand to see corporate training materials given to software "engineers" (I concur on the quotes) on how to promote product safety.

My school required a software-focused ethics course in order to graduate with a CS degree. It was great—one of the few courses that I lean on on a regular basis in my work.

Good on you for taking it as an elective, but it's weird to me that any degree in any topic can be accredited without having a mandatory ethics course, let alone a degree in a science/engineering field.

Would love to hear some specifics from the course that come up for you at work!

Agreed and thanks! I actually didn't realize that tweet reply to your original reply was also from you - it's what got me thinking about clear engineering codes of conduct in the first place.

I sat through a very similar class once upon a time.

I'm glad Ethics for Engineers wasn't an elective but mandatory when I was in school.

I think you're totally right. But I also think: If an alien visited our planet and saw the same decision being made, its reasonable that they may ask: Wait, why can't you just do this in software? Is your software really that bad?

Point being; the software industry is deeply dysfunctional; and the best people who aren't steeped in software every day can do to influence their decision making process is to trust and listen to the people who are. Software engineering is as much Engineering Software as it is Navigating The Absolute Dysfunction of our Software Landscape; actually now that I type that, I think its significantly more the latter.

I don't know if anyone is trying to fix this, or at least do better. I really hope so. I've been on major teams at three systemically critical internet companies and its not getting better; its getting worse. It scares the living daylight out of me that the biggest thing holding everything together is PagerDuty.

> Wait, why can't you just do this in software? Is your software really that bad?

Fly-by-wire in airplanes is pretty good, but it still has its problems, and a lot of verification work goes into it, probably more than embedded Windows.

In some jurisdictions, software engineer is a protected job title that requires professional licensing (ever wonder why Google only hires "developer" in their Waterloo office but "engineer" elsewhere?). IIRC the engineer that wrote the code for the Volkswagen scandal was jailed for failing his professional obligations.

For OP's case case, I'd assume/hope a professional engineer would need to sign off on this change or be able to tell the VP to f off.

Hardware came from oversees and there was no licensed PE on the US side. But you're right, there should have been.

This was before the device was submitted to the FDA for approval. Chance they would have rejected it. A fallback position for a developer not willing to Play It Hard would be to make sure the risk docs submitted to FDA document this failure path. There is a whole process you are supposed to go through to analyze risks / harms and whether your controls are adequate.

Back when I was studying Computer Science, the fact that Computer engineering is not engineering was a very hot topic. Engineering comes with certain guarantees. If a you don't put a load more than X on a bridge for the next X years. It will not break.

How can we offer that guarantee as a profession when hardware, drivers, OSes and even libraries that we use change and shift without our control and sometimes consent?

Software "engineering" will definitely need to be looked at differently from physical, but there are still things we can do.

Critical systems (or at least the critical subsystems) must not allow any unapproved/untested changes. Hence why it's better for safety controls to be hardware/firmware and not part of a general-purpose OS.

It's one reason why you see separate payment terminal hardware on self-checkout kiosks. The payment hardware is more tightly controlled whereas they can modify the kiosk much faster.

There are also RTOS (real time OS) that offer execution time guarantees. Used in aerospace.

The labor pool of software engineers is very diverse in terms of backbones, ethics and morals. It puts replaceable engineers in an awkward spot to object to unprofessional requests.

For an anecdotal example, I have been told that standing up for ethics in software engineering would have negative consequences on my performance (implied: bonus, promotions, career). I have left that company, and they probably found someone more agreeable to replace me.

I don't know how we can force ethics onto companies, especially large corporations who receive thousands of applicants into engineering roles each week. There do not seem to be good incentives for engineers to be overly concerned with the overall ethical impact of their work. And so there are many engineers who won't ready to replace those who would.

What happens in other engineering disciplines is the government revokes your license if you make a decision that violates your discipline's standards. Companies can't generally just force their engineers to do irresponsible things because even if they fired you and hired someone new, that new person would be putting their own future employability on the line by conceding. Better to get fired from a bad firm than to have to find a new career.

Obviously this doesn't solve all the problems, but it works as well as any solution I can think of.

The caveat when it comes to software is that coming to a consensus of what the standard procedures and policies should be would be nearly impossible. If and when software joins the licensed engineering fields, a lot of people are going to be very upset at whatever the requirements end up being.

The caveat is very true, and I think that I would be unhappy if a licensing body told me I'm suddenly "not qualified" to do the work I've been doing well for many years. Besides, it wouldn't be just for me to bear licensure costs (whether direct or indirect by being out of work while I get licensed) to correct an ethical fault in companies.

Perhaps licensure could be an effective solution, but one that is not very empathetic to engineers. Maybe some kind of a government-owned ethics controller/body to handle unethical software would be more just for engineers. Although it could also be very inefficient.

The profession and the state have to choose between freedom and regulation - or some hybrid compromise. For computer types, the profession and the state have opted for freedom. I'd say that on balance it was the right decision. For other professions (doctors, layers, accountants) that balance has been achieved and codified over may generations.

For egregious ethical violations, the whistleblower act provides a remedy.

As others have noted, professional licensure (which can be revoked) is used in other industries.

Not feasible to ask this for every developer, but for safety critical systems it should be mandatory.

> The labor pool of software engineers is very diverse in terms of backbones, ethics and morals.

This is exactly my point. The same is true for other engineering disciplines, too, but by codifying their ethical responsibilities (and, in some cases, assigning liability to engineers who forego those responsibilities), other professional engineering organizations help to ensure a bare minimum for what is and isn't allowed in their profession.

I'll give another example that has much less dire consequences than the OP's. 90% of "scarcity marketing", e.g. "Act now! There are only 2 rooms left!" or even "8 other people are looking at this property!", is complete and total bullshit. I've even seen A/B tests where they developers were like "yeah, the data here is not real, we just want to see if it has an effect." Why is this even in the realm of acceptability? There is no gray area here - it's not just a "dark pattern". It is 100% outright lying. Yet I never heard someone stand up in those product reviews (myself included, so I'm no hero either) and say "How can we spend so much time on our 'company values' when this is obviously bullshit and slimy?"

I wish there were a "software engineering code of conduct" that said that outright lying to end users is verboten, and that software developers can be held personally liable if they are aware of the lie and still implement it.

Both the ACM [0] and IEEE [1] have published Codes of Ethics, but I agree they have little teeth.

[0] https://www.acm.org/code-of-ethics [1] https://www.ieee.org/about/corporate/governance/p7-8.html