Engineering ethics
leancrew.com
leancrew.com
> Listen up, this will be on the test. You need to help patients, not hurt them. You need to be responsible. Try to avoid being irresponsible. Try to act professionally, and to be a positive asset to society. Don't abuse nurses. If someone asks you do to something unethical, tell them you won't. Did I mention you need to help patients, and not hurt them?
> If reading that paragraph seemed like a waste of your time, imagine how I feel after attending the three hour lecture version.
That's from Against medical ethics[1], an early post by psychologist Scott Alexander, who has since started writing at http://slatestarcodex.com/
People writing this sort of software either don't think they're causing harm, or they rationalize it. If the writer of malicious or deceptive software doesn't realize they're doing harm, no programming ethics course will help. The same is true if they rationalize their behavior with reasoning like, "If someone is dumb enough to get this spyware, they shouldn't be online." or "If I stopped doing this job, someone else would take my place tomorrow."
I'm not sure what the best solution is, but ethics codes seem like a complete waste of time.
Treat other people as you would want to be treated. Don't murder or steal. Be respectful and empathetic to others.
Yeah, you can say they're trivial platitudes, and anyone can reason themselves out of them on technicalities, but I don't know if the world would be a better place if we just threw them all away. They're norm setting, not legal documents.
ETA: Hell, maybe it's best just to think of them as a checklist. Yes, don't do these obvious things W and X, and do do these other obvious things Y and Z. And even if it seems ridiculous that that would appreciably improve behavior, checklists of other things--like washing hands--have been shown to significantly improve policy compliance and outcomes.
Checklists augment human memory, preventing people from forgetting parts of frequent, repetitive tasks. I don't think people forget parts of their ethics often. They might "cheat" a little for impulsive decisions, but that's the extent of it. If you spend weeks applying, interviewing, and accepting a position making malware at a company, it says a lot about you as a person. That's where the vast majority of malware comes from, not otherwise ethical people who sometimes backslide.
Obviously there are people out there who will never care about making ethical decisions, but I think there are situations where an otherwise ethical person might do something unethical without being aware of it. Malware doesn't count, since obviously no ethical person would do that (excluding arguments about intelligence agencies and warfare...), but a good target audience might be engineers working on software that has the potential to infringe privacy.
Deciding actions based on consequences is utilitarianism, which is only one ethical system. There's a number of other systems. For instance, one could have a set of rules that they follow (e.g., always tell the truth), but that could result in negative consequences.
Well, except for rule utilitarianism, which on one level is anti-consequentialist (though on other levels it's still deeply consequentialist).
Rule utilitarianism has some things in common with deontology, but it's quite different in others.
If we had, in addition to an ethics code, a state body that could take people to task for violating it, then it could have teeth.
Of course then the unethical programmers would all move to Nevada (or whatever state had the most lax oversight). One step at a time, though. :)
[1] ]http://www.e-laws.gov.on.ca/html/regs/english/elaws_regs_900...
However, even in Canada the vast majority of software developers are not professional engineers.
Not directly on-topic, I read this about an hour ago... http://en.wikipedia.org/wiki/Michael_Swango, an article about a doctor who was a mass murderer, and was eventually caught after killing something in the range of 30--60 people, and provides an interesting counter-point to the effectiveness of medical ethics. I admit that it's an edge case, the exception rather than the rule, but even ethics training and oversight isn't effective against a bad actor.
"(I am, by the way, curious what programmers think of the topics covered by the exam[1].)"
Speaking a professional programmer for the last 25 years, my take on the topics is that they heavily over-represent things about software development and are rather thin on actually doing software development. I would really, really, like to see a similar document for mechanical or civil engineering.
A while back, I wrote some notes[2][3] for the references to the IEEE Computer Society's Software Engineering Body of Knowledge (SWEBOK), which I think is the basis of the exams.
As for engineering ethics in software development, I personally would be overjoyed if we followed even the old-school system[4].
[1] https://cdn.ncees.org/wp-content/uploads/2012/11/SWE-Apr-201...
[2] http://maniagnosis.crsr.net/2011/11/consolidated-reference-l...
[3] http://maniagnosis.crsr.net/2011/11/consolidated-reference-l...
[4] "Thou shalt not compete with another engineer on the basis of price."
The mechanical engineering exam tests your knowledge of the various sub-topics within the field. It covered thermodynamics, dynamics, fluids, vibration & control, heat transfer, etc. In addition to that there was a section on ethics, and a short bit on accounting/economics.
I had imagined a software engineering exam might have sections such as algorithms, data structures, concurrency, cryptography/security, etc. Basically it should prove that you have a complete, broad, knowledge of the field. The questions in each subject matter are not particularly hard, but I can be sure someone that passed the mechanical engineering FE has a basic understanding of every topic covered in a bachelors degree.
You then need to have 48 months of experience and they need to include things like leadership experience in addition to just domain expertise. It then is sent to a committee which decides if your experience meets all the criteria.
1 Professional engineers and geoscientists shall, in their areas of practice, hold paramount the health, safety and welfare of the public and have regard for the environment.
2 Professional engineers and geoscientists shall undertake only work that they are competent to perform by virtue of their training and experience.
3 Professional engineers and geoscientists shall conduct themselves with integrity, honesty, fairness and objectivity in their professional activities.
4 Professional engineers and geoscientists shall comply with applicable statutes, regulations and bylaws in their professional practices.
5 Professional engineers and geoscientists shall uphold and enhance the honour, dignity and reputation of their professions and thus the ability of the professions to serve the public interest.
Was wondering though, if you know, does having an "engineer" in the title help with the salary.
Like say at a software company in Canada and I am a "developer", but say if my title became "software engineer" with all the extra accreditation of course, how much more would I expect to get payed more year?
Things are pretty much still treated interchangeably here in most lines of work so unless you're in a business that traditionally relies on engineering work and stamps you wont get any preferential treatment.
If you're in an engineering department at a university, getting the P.Eng is advisable as they need a certain amount to be accredited. I think in that case there's a pay bump.
-> Perform services only in areas of their competence.
It makes some sense, for example, that a mechanical engineer specializing in control systems not sign off on the structural analysis of a building. Or for an electrical engineer to sign off on a refinery reactor design.
However, in software, we are all (or should be, at least) constantly working on things outside our current skillset. This sort of requirement harms cross-disciplinary training and encourages the binning of software folks into ever-narrower positions, with all the pay and market impacts that implies.
-> Issue public statements only in an objective and truthful manner.
This is something we're terrible at, and honestly one could argue that it stifles a lot of what makes open development so effective.
I kind of disagree with you here. Professionally I code the software that runs Control Systems for various industries. The software design must match a electrical spec that is written by one of our Electrical Engineers. So although my work might be dipping to the agricultural or civil or mechanical engineering domains I must collaborate with a qualified engineer to meet spec.
The way that statement is written is not to say that myself as a controls developer cannot branch into web or mobile development though I'd argue there are certain software fields not everyone should be practicing without some rudimentary training and proof of competence (anything security related, or any branch of software that interfaces to real world components).
I don't want a self-taught web front-end coder writing code that handles the security of my financial information. I wouldn't necessarily trust a corporate programmer writing billing software to write embedded drivers. That's not to say people can't be hobbyists though. People dabble in electrical hobbies all the time but they don't market themselves professionally as "Engineers" either like many do in Software.
You know how many developers that is today, though? Especially given the vast gap between how software engineering is taught and how it is practiced?
I wouldn't necessarily trust a corporate programmer writing billing software to write embedded drivers.
Have you seen the great lengths assembly hackers at, say, BMC, go to to make sure their legacy code modifications keep running on turducken VMs? I would trust those folks to write embedded drivers if the project was spec'ed properly.
That's the whole point, though: in our general discipline it comes down to collecting data, transforming data, and persisting data--the actual type of data matter relatively little, and introducing these arbitrary "Oh, you're a frontend JS guy, you shouldn't work on my backend transaction processing system" restrictions only hurts us.
If the JS guy wants to go through the rigor to learn the tools to be a great security expert he should be able to. Heck, I wouldn't refer to him as a "JS guy" at that point anymore either. I want an industry where there is a vetting process to prevent frauds or incompetence from creating issues prior to the issues existing. Some amount of assurance, or accountability. We currently sort of work on "best-intentions" in that regard.
Engineering in it's traditional fields has gone through this growth pain. In some cases many lives were lost in the process of learning that there should be a regulatory body overseeing who is allowed to sell themselves as competent practitioners. Consider the state of OpenSSL when Heartbleed came about. There was most definitely a series of fundamental issues at play that weren't brought to light until after its hayday, but as an industry we sort of have the mindset of "these types of things are inevitable". I can't say concretely where I stand on the matter but I do believe a higher level of accountability would be a net positive for public perception. This is a very loose example, its a complex topic that would take far longer to debate in full I think.
On the flip side too is the idea that "Software Engineering" becomes a protected field where its important. I mentioned my domain is control systems, but so many of the tools I work with are years behind more modern frameworks and technologies that are used outside my industry. I have embarrassingly low amounts of tools to test the programs I develop, its mostly a rigorous manual testing procedure that gets done to say I'm satisfied and I'm responsible for this application. I blame, in part, the fact that this work is more often done by Engineers in other domains. They don't know what modern software development has overcome and created. Some of the routines and applications I inherited moving to this position were embarrassingly poor and thankfully never caused real-world harm mostly due to the numerous tiers of safeguards that exist in designs. Its like coding with exceptions but being fine with it because there's a Catch somewhere higher in the operating environment.
I suppose I might be in the wrong place here as this is HN a more Startup-centric tech forum. I've long disagreed with the mindset that software engineers need to "upset the established norm" in a lot of fields. Medical is a big one lately that's getting a lot of traction. There's a balance that should exist between regulated gatekeeping of fields for the public good and legislated protection over fields to prevent outside interaction.
I feel I've ranted a bit. This truly is a complex topic which I think I'm still establishing a position on as I grow and get experience in the industry. I know where we are _currently_ isn't right in the long run, but taking the term "Engineer" to be as by-the-book as possible to the traditional fields of engineering isn't right either.
Oh, he will be. Of course, now you have to trust the vetting organization to actually do their job. And why exactly would they, if it's better to raise prices and vet anyone who can afford them?
I want an industry where there is a vetting process to prevent frauds or incompetence from creating issues prior to the issues existing.
And in which industries does that happen already? How can you tell it's the vetting process (and not any other factor(s)) that is reducing the fraud and incompetence?
So, I absolutely appreciate that there are nuances to all of this, and I'm glad to see you thinking it over.
I think some of the things we absolutely do wrong as an industry:
-> lack of common nomenclature for problems (design patterns comes close, but then we look at all the buzzwording of other things, and argh)
-> lack of language-standard test suites for things. There are more than five or six, for example, for JS, all of which scratch a slightly-different itch. This is absurd.
-> lack of domain-standard test suites for things like numerics. We can't easily and reproducibly compare implementations across projects or languages for different problem domains.
-> lack of standard engineering practices for team development and project management.
Those are things that, I think, we could at least establish baselines for without jeopardizing our ability to deliver cool new shit on time.
Also, isn't the whole point of engineering to screw around looking for something new where we don't know a lot. The "work only in an area of competence" sounds a lot like let's bring back apprenticeship and try and create a static craft instead of endorsing dynamic exploration in field where we assume most things aren't yet discovered.
If anything, that's the diametrical opposite of engineering. One of the objections to "software engineering" as an engineering discipline is that there isn't enough history from which to draw conclusions on best practices.
> The "work only in an area of competence" sounds a lot like let's bring back apprenticeship and try and create a static craft instead of endorsing dynamic exploration in field where we assume most things aren't yet discovered.
One point of professional licensure is to demonstrate a minimum level of competence. Practicing outside of one's area of demonstrated competence defeats this purpose of licensure. Nothing prevents a mechanical engineer from designing a circuit, but they sure as hell aren't going to stamp that circuit diagram.
> 5. Avoid deceptive acts.
Knowingly programming dark patterns into apps is breaking rule #5. If you're a chemical engineer and your employer tells you to put a misleading label on a batch of chemicals, you can feel very confident saying no to that. The chemical engineering community and culture strongly discourages the "just following orders" excuse, and they push for openly fighting management on unethical or misleading practices.
However, if you are a software engineer and get assigned to program a misleading pattern into an app, most people just do it. Also, slapping together a shitty program due to lack of resources is common, too. It seems that management is the driver of quality and ethics in software engineering. I hope someday, like in other engineering sectors, software engineers have the culture and confidence to stand up to management on ethical matters.
In software, you can often have people with no technical knowledge managing software procurements. In traditional engineering we understand the importance of the owner's engineer(s) and site representatives to completing a job properly.
I'm not so sure. Most people who want a building made, for instance, wouldn't know if the electrician did it right, or if the foundation was laid using the best methods, or if the right materials were used.
Instead, you have a inspector come and verify the work.
When you are constructing a building, the owner hires engineers to oversee the work done by the general contractor. There are a lot of intricate details here, but the work is exactly as the parent to your comment described.
My brother is one of the owners rep for structural work on a 60 story building going up in Manhattan right now. They're pouring an 8' thick foundation tomorrow. The people involved are all engineers working for the developer, and the inspectors aren't showing up until after the fact.
How does a test make you ethical? Norms keep folks ethical.
I see these tests as mostly a protection against new people entering a field.
It's also standard to lock folks into working under "qualified engineers" for a number of years, which seems unnecessarily burdensum and counterproductive for an expanding field.
That said, I put the term "Software Engineering" right up there with "Computer Science" in terms of descriptive value.
I prefer "Software Developer" myself.
Until then it's about as meaningful to me as someone going. "Perhaps you can action multi-cultural ethics to leverage an enhanced-value culture producing more positive client relations... through... synergy?"
"It is more important that innocence should be protected, than it is, that guilt be punished; for guilt and crimes are so frequent in this world, that all of them cannot be punished.... when innocence itself, is brought to the bar and condemned, especially to die, the subject will exclaim, 'it is immaterial to me whether I behave well or ill, for virtue itself is no security.' And if such a sentiment as this were to take hold in the mind of the subject that would be the end of all security whatsoever."
If you want people to behave virtuously, then you need a system where if they're punished, or accused of something, their virtue is a defence. And where that which is malign to the virtues you're attempting to foster is punished (though as Adams suggests, I would suspect that the balance of this should be more towards the former than the latter.) Else there will be little reason for anyone to do so, it will just be a faster way for their life to be worse.
Therefore, if your system has no influence upon the risks and rewards for behaving virtuously or otherwise, I believe it is more a CYA policy than anything else. Like companies that twattle on about their culture and then you ask them "Can you give an example of something you've done in the last year to encourage X?" And you see their gears spin and know they're selling something that doesn't exist.
This is the fundamental problem with licensure: you start with the premise of "there are bad and/or incompetent people", then try to solve it by... having those same people judge each other. Its a circular solution, only now you also get politics. Do you really think these state boards would apply the same scrutiny to NSA backdoors? Of course not, all of a sudden the seemingly clear cut ethical questions brought up in this post would through the magic of politics become "difficult subtleties".
I want to put my valuables in a safe, not make everyone take an oath to not steal.
#1) Getting an accredited engineering degree #2) Passing the Fundamentals of Engineering exam #3) Working as an engineer (typically under the supervision of a licensed Professional Engineer) for several years #4) Passing the Professional Engineer exam
If you haven't done those things, you can't call yourself a Professional Engineer (capital letters).
I don't see how that is circular. Are you saying the people that have jumped through those 4 steps are potentially incompetent? I can believe the argument that some non-PE's are better engineers than some PE's, but I don't believe the argument that the people that are PE's are incompetent. I've never met a PE that was a bad engineer.
We are mixing in a lot of unrelated things (tests, apprenticeship, etc) to guise what this actually is: a club where existing members are the gate keepers for new members. This is the circular part, it serves the purposes of the members, not the customers -- notice how the users and customers don't figure into any of the 4 steps you mentioned in licensure at all -- they aren't empowered, they are now "protected" by the very same set of people we determined needing wrangling in in the first place.
Aside from the trivial chicken and egg problems (who decides the initial PEs? who decides the first exam?), we have the very real concern that the most connected current software engineers in government are precisely the ones that are probably currently breaking the code of ethics (writing malware for national security purposes). This highlights the issue with "self judgment" and makes me incredibly skeptical of the opinions of such a potential licensing committee.
Software engineering is not mechanical engineering. There's very little known "for sure", and it doesn't compare to the kind of experience we have building a bridge (there are people who can make really good arguments that mutability is "unsafe" for customers, or that strcpy vs strncpy, or hell, C being used at all). This makes this area ripe for abuse, and to have licensure used to propel the interests of the licensees and not the customers (some more thoughts on that here: https://www.youtube.com/watch?v=8q71hrwUcu0 ). I doubt a "financing license" would stop wall street behaving the way it does, given the existing ethics and how everyone in power there is also connected to the government.
All this of course, in contrast to us working hard on making security and encryption accessible to our customers.
Of course. As we all know, real engineers drive a train.
chugga chugga chugga chugga chugga chugga CHOO CHOO! chugga chugga chugga chugga
I also think that many firms that design consumer products aren't run by PEs. So it may not be a universal requirement.
In my opinion the most analogous type of engineering to the average web dev shop is HVAC. Every building needs someone to design the HVAC system, but it's pretty routine work. There explicitly is a PE exam for that type of work, which seems like overkill to me, even though I'm very much in favor of PE exams.
Being a professional means that you have ethical obligations that supersede managerial authority. It's debatable how often things actually work that way, but that's the idea. On one hand, this increases your personal responsibility (you can't use "following orders" as an excuse) as a professional. On the other, the professional is protected by boards and certifications and limits on the labor supply that give him leverage, because even if he's fired, he's still certified as being worth a damn. If anyone can enter the labor market, then bosses become the sole source/record of credibility-- getting laid off is no big deal, but a bad reference can and a career-- and hold all the cards, which means that employees have no moral agency. On the other hand, if there's a minimum level of credibility to be part of the profession, then (at least in theory) each professional has sufficient credibility to work independently and therefore has no reason to fear management, and therefore can push back against unethical orders (and is required to do so).
I think it's obvious that the VCs and the wage-fixing tech barons of Silicon Valley would fight such a structure, should it emerge, with all that they've got. They hold all the cards now, and a union or professional guild would threaten that, and they're very good at convincing a surprising percentage of engineers (perhaps due to the age discrimination culture, which favors naivete over experience) that interests are aligned between the side of the tech barons and investors and serial founders and that of the engineers, never mind any evidence to the contrary.
In 2008, in the US, almost 30% of the workforce had a professional license, up from less than 10% in the 70s. Has there been a similar increase in the moral agency and ethical standards in the country?
Replacing a wage-fixing elite with another is not my idea of a solution, to be frank.
I can say that ethics is a core part of engineering curriculum from day one, and one is repeatedly reminded that one is expected to exercise their "moral agency".