Slashdot Mirror
First, Do No Harm - A Hippocratic Oath for Coders?
rhysweatherley asks: "With the increase in spyware, spam, etc, is it time for a Hippocratic Oath for Programmers? Should programmers be able to refuse to write code that harms the public more than it helps? Should they code defensively to prevent software and information being misused for unintended purposes? And how do we protect such programmers from being dismissed unfairly for standing on principle?"
they'd just fire you and hire someone else. If you are unwilling especialy now there will be 10 other people willing to do it and take your job if you aren't.
You're missing the point. First of all, I don't think there's 91% unemployment among software developers. Secondly, if there was any kind of organization among programmers independent of the employer then the employer would have a hard time bringing down this type of action.
I don't think a "union" would occur, but I wouldn't be surprised if a professional organization of ethical programmers would arise. I would imagine members could fetch a better salary, especially if there was some competency requirement, as doctors have the Medical Board exams.
It would hurt the self made programmer, but I would certainly rather see that type of accreditation than what we have today: MCSE, MCSA, etc...
My Karma was at 49, then they switched to words. All that work for nothing!
True enough, so let's get to the real meat of the issue.
<P>
Doctors take this oath, and follow other rules, as part of being a <b>certified</b> profession. To be a certified profession means there is a governing body, and often the government, which defines whether you are a doctor or not, and defines whether you can practice medicine.
<P>
Certification makes sense in a very limited set of professions where the practicioner will be doing something life-critical like cutting you open, or defending your freedom in court, or designing a bridge for you -- and just as importantly, in cases where you have a consulting relationship with the professional rather than an employment one.
<P>
If you're going to trust somebody you barely know with your life for a short-term contract, you bet you want some external means of certifying that they are capable of the job.
<P>
But with a very few exceptions, programming and sysadmin are not like this. THere are of course many consultants, but most are actually employees. Instead of the government defining who is a programmer, the employer decides who they want to hire.
<P>
What would an oath for programmers mean? Would there be a certifying body checking things? Would it get to define who was a programmer? Would somebody not be allowed to be a programmer if they didn't take the oath?
<P>
That's not what we want.
Has it been over a year since you last donated to the Electronic Frontier Foundation
The Geek Oath would be even worse off when it comes to gray areas. For example:
I used to work at a (now defunct, like the rest of 'em) dot-com. Our software was, by most definitions, spyware: If you downloaded and installed our software, it would keep track of what you listened to (via pretty much any media player -- we had the top twelve or so covered by the end) and send that info to our servers, which would respond with a wealth of information -- current news, tour dates in your area if you so chose, new releases, etc. The longer you listened, the more information you would get -- "Oh, I realize you're not listening to Radiohead right now, but by the way they've got an album coming out..."
Now: a) We never attempted to sneak onto someone's system; b) We made the uninstall as painless and obvious as possible; c) We never hid the fact that we were sending back listening statistics. But still, we *were* monitoring what you were listening to.
So would I have been in violation of this theoretical Geek Oath?
(Save your flames and your "I'd never!"s -- fact is, a lot of people did, myself included. It just Didn't Work Out, but our management handled the end -- once it was obvious that it was inevitable -- very well.)
The basic idea behind the ACM code of ethics, which was first developed in the 1960's (but has been amended many times since) is to avoid being specific or definitive in any way. There are good reasons for this that were published in an ACM paper titled "Rules for Ethics in Information Processing", by Donn B. Parker in the ACM journal for March, 1968, describing the reasons that the code of ethics was designed how it is.
If you look at the code of ethics carefully, there are virtually no declarations in the entire thing that state "thou shalt not" or "thou shalt". If there's anything that says that, it puts the judgement of what it means on the member themselves.
When it comes down to it, the code of ethics is more of a requirement that ACM members use their common sense and do what they truly believe is right and ethical in a way that is within reason acceptable to society. Every single person has their own idea of what is ethical, and the boundaries are very fuzzy. As soon as you start drawing lines, you create as many problems as you solve.
It has been used in the past to kick people out of the organisation. I think one of the first times it was used was to dismiss a member who'd put workarounds in some banking software so that his own account had certain financial advantages over everyone else's... or something similar. He was put before a committee representing ACM, he couldn't ethicly justify what he'd done in a way that satisfied the committee, and so he was thrown out.
The ACM paper above is a good read about why it isn't a good idea to have a strict code of ethics. Personally I think the ACM approach is a good way to do it.
This works. Very few structures fall down in the developed world because of engineering errors.
One way would be to require that programs whose malfunction can cause nontrivial harm be signed and sealed by a registered professional engineer, the way building plans are signed. To give this teeth, certificates for code-signing would be issued only through registered professional engineers.
Someday, programming may grow up and go this route.