February 5, 2009 at 9:00 am
As I've read through the responses a common theme has been that people already know what is right and wrong or moral or ethical, yet can someone provide a definition and where that definition comes from?
The issue, as I see it, is that, when placed in a situation where we have to choose, we too often fall back on "It depends" instead of having a clear standard. I won't lie, unless it is to spare someone's feelings. I won't steal, unless I need to feed my family.
I think having a defined Code of Ethics is a good idea just so there is a standard to point to when a new person enters the field or when questioned about why we can't provide that information. Sure it can't be enforced like in a licensed profession like the medical field, but we can, as a community, use it to try to weed out unethical people and point to it when hiring as a condition of employment.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
February 5, 2009 at 9:12 am
The ironic part about this whole discussion is that a code of ethics would only be followed by ethical people. 😉
--Jeff Moden
February 5, 2009 at 9:17 am
Jeff Moden (2/5/2009)
The ironic part about this whole discussion is that a code of ethics would only be followed by ethical people. 😉
Not the point. Having and briefing about a code of ethics should raise awareness - it's not an on or off thing, and you can become more aware of the ethical implications of a given situation, and realise you can do better. And having people signed up to a code makes it easier to show when they failed to observe it.
February 5, 2009 at 9:19 am
Andy Warren (2/5/2009)
I don't think ethics is that easy, and I'd rate myself pretty high on the ethic-meter. Don't lie/dont' steal are fine, but what about gray areas?- As mentioned, a SQL injection vulnerability that you know could expose privacy/credit card data? Do you quit? Call the FBI? How long do you give them to fix?
- What if an employer wants you to provision a new SQL Server, but wait to pay for the SQL license when SQL 10/11 ships. Technically stealing, do you say no? Quit? Report them?
- How about if your CIO asks for a spreadsheet of all customers with a credit line of more more than $25k (name, address, account #). Do you provide it? Ask him to state he's not going to mis-use it?
- Or you discover that your offsite backup plan consists of the network guy taking the unecrypted tape home with him every night, he's a drunk, getting divorced, and has money problems - what is your role in heading off possible data loss?
Maybe it does come down to don't lie/don't steal. I think the problem with very fixed rules is that they actually give us a way to avoid the gray areas, and that's where the pain often is.
I'm just arguing my view, but it's a good discussion.
It comes down to what you agreed to do for your paycheck. Your gray areas don't seem all that gray to me. I'm not meaning to sound argumentative or draconian, this is truly how I see it.
SQL Vulnerability: Are you the one responsible for data integrity? If so, FIX IT. If you aren't, report it to the person who can fix it, or their boss. Keep an eye on it, and escalate to their boss's boss if it doesn't get fixed. If you aren't responsible for data integrity you aren't really a DBA, right?
At that point (as a non-DBA who stumbled across it) you should report it as a good Samaritan, but that's all.
Provision an unlicensed server: Refuse. I've been in this position, I refused. They bought the license. 🙂 This is not gray. (I never said I was flexible. 🙂 ) If they push it, don't back down. If they fire you, and you feel like causing trouble report your company. If they go around you and don't fire you, you should probably look for another job anyway, as your boss is clearly not to be trusted.
CIO request: Honor it. He "owns" the data, or is an agent for the owner. It is his data to request.
Offsite backup: If you have the authority make other arrangements immediately. Failing that, notify your boss and his boss. This *is* a data breach and if your immediate boss(s) won't act escalate to someone who will.
I've had to stress to the president of our company on occassion how vulnerable we would be to ruinous lawsuits if a data breech occurs. On a regular basis I am urged by well-meaning but clueless users to include sensitive data in systems where it has no business being. I refuse and start educating them about how dangerous that data really is. So far I've been successful and avoiding including social security numbers and driver's license numbers and the like.
It all comes down to what you and your employer agreed to in the beginning, and what areas you're responsible for. By keeping your word even when it's hard your employer knows he can trust you to honor your agreement.
And that makes you solid gold in this world of ours.
As I said, my view may be too black and white for some people's taste, but it works for me.
February 5, 2009 at 10:08 am
About 4 years ago, a group of computer professionals specializing in a different discipline had a similar problem that might be beneficial to look at. I'm speaking of GIS (Geographic Information System) professionals.
There was a strong feeling for the need for some sort of certification program, but it needed to not focus on any one software vendor. The solution was that several professional organizations (not vendors) formed an independent body, called the GISCI (GIS Certification Institute). It now offers a program to become certified as a GISP based on points earned through education, work experience, contributions to the profession, and signing a code of conduct statement.
Please check out their information at www.gisci.org. There is a link to their Code of Ethics, which could be easily adapted to DBAs. Or perhaps an entire DBA certification could be modeled after theirs, with an eye towards not making it vendor specific.
Ray Montgomery, GISP
Sandy City, Utah
February 5, 2009 at 10:47 am
The supposed issue of a code of ethics for Database Managers is a non sequitur of unbelievable proportions because:
1. Ethics imply metaphysical benchmarks from which an agreement of all parties can be established as to what specifically differentiates good DBA philosophy from bad.
2. DBAs being essentially rational and logically oriented in their prioritization of duties can immediately discern the nature of issue 1 above being unanswerable and pointless to pursue given our post-modern culture which denies the existence of metaphysical standards on the basis that they are essentially byproducts of cultural and tradition and have no foundation in the classical understanding of truth, thus no code of DBA ethics has been nor will be established.
3. The professions of physician, attorney, accountant, engineer, realtor, et al, which were made example of for their codes of ethics are today better recognized for their collective violations of said codes than they are for their promotions of and adherence to those codes.
4. Most of the references provided in the editorial speak of Service Level Agreement goals not ethical standards of performance.
I would suggest that the topic be reframed around the title of SLAs for DBAs
February 5, 2009 at 11:03 am
Jeff Moden (2/5/2009)
The ironic part about this whole discussion is that a code of ethics would only be followed by ethical people. 😉
True.
And even professions with published ethics rules can have huge problems with it. You can be disbarred for a large number of things as a lawyer, but is there anyone left in the world who actually believes lawyers are highly ethical? (If so, I have this bridge, and there's a deposed African ruler who wants to buy it, but he needs a bank account to transfer the money through, and you are his choice for that.)
And most people understand that doctors, while often ethical, are equally often more motivated by money than by a desire to help people have better, healthier lives. Depends on who you get.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
February 5, 2009 at 11:26 am
I don't think SLA for SQL is the right approach, but maybe it's not pure ethics either. I guess one question I have is "who benefits from having a written set of ethics for a SQL DBA?"
- I think new DBA's might find it pretty useful to know what is expected of them ethically beyond dont lie & steal
- If you're a strongly ethical person you don't "need" the list, but in most cases wouldn't your standrds be higher and so doesn't hurt (but doesnt help)
- I think it's useful (if wimpy at times) to point to an external source (like a consultant!) and say, NO - because blah blah is written here
Rather than be abstract, here's an first cut with not much forethought!
- I will notify my employer of any potential security gaps that directly relate to SQL Server and their perceived severity
- I will not sell, trade, etc, data that I have access to as a DBA
- I will notify my employer if I believe them to not be in compliance with SQL Server licensing
- In the event that privacy data has been breached, I will notify my employer and if no corrective action is taken within X, notify authorities
- I will advise my employer of 'best practices', but I understnad that my employer may choose whatever practices are deemd appropriate (too loose??)
And then supplement that with some cases/guidance. SQL injection. Not using encryption with privacy data. Etc?
February 5, 2009 at 11:48 am
Here's an extract from that GISCI Code I referred to earlier. PLEASE NOTE that this is just a summary. In the actual code at http://www.gisci.org/code_of_ethics.aspx each of the numbered items below the topics has several bullet points that fully explain each one in detail. There is also a discussion before the actual code about how it was developed and the goals.
Just substitute "DBA" for "GIS Pro" below, and see how it reads:
I. Obligations to Society
The GIS professional recognizes the impact of his or her work on society as a whole, on subgroups of society including geographic or demographic minorities, on future generations, and inclusive of social, economic, environmental, or technical fields of endeavor. Obligations to society shall be paramount when there is conflict with other obligations. Therefore, the GIS professional will:
1. Do the Best Work Possible.
2. Contribute to the Community to the Extent Possible, Feasible, and Advisable.
3. Speak Out About Issues.
II. Obligations to Employers and Funders
The GIS professional recognizes that he or she has been hired to deliver needed products and services. The employer (or funder) expects quality work and professional conduct. Therefore the GIS professional will:
1. Deliver Quality Work.
2. Have a Professional Relationship.
3. Be Honest in Representations.
III. Obligations to Colleagues and the Profession
The GIS professional recognizes the value of being part of a community of other professionals. Together, we support each other and add to the stature of the field. Therefore, the GIS professional will:
1. Respect the Work of Others.
2. Contribute to the Discipline to the Extent Possible.
IV. Obligations to Individuals in Society
The GIS professional recognizes the impact of his or her work on individual people and will strive to avoid harm to them. Therefore, the GIS professional will:
1. Respect Privacy.
2. Respect Individuals.
Ray Montgomery, GISP
Sandy City, Utah
February 5, 2009 at 11:51 am
Unfortunately, no matter how you approach the term "ethics", you must deal with the 800 pound gorilla which is what defines right and wrong? Who says? On what basis? When these questions can be answered, then we begin to approach the discussion of ethics. Otherwise we are simply making noises that no one can rationally interpret. This is why I suggest continuing such a discussion with emphasis on SLAs which are simply the establishment of performance goals which are what we are really discussing here.
February 5, 2009 at 12:19 pm
This has been an interesting discussion so far. After reading all of the postings, it seems that the majority of the DBAs in this discussion aren't interested in a DBA Code of Ethics, with only a few people in the "maybe" and "yes" categories. This is a good indication why this topic has never "caught on" within the DBA community.
One thing I have noticed about the "experienced, professional" DBAs I personally know, is that they take their job and DBA responsibilities very seriously, and because of this, a DBA Code of Ethics is redundant for them. I think most of those in this discussion fall into this category.
But as Andy Warren suggested, a Code of Ethics might be useful for those new to the profession. I agree. A DBA Code of Ethics (and a very general one at that), might be useful as a guide for those starting out. Also, as Andy has suggested, a DBA Code of Ethics might something DBAs might be able to reference if they are stuck in an ethical dilemma and need support for their position.
While I did briefly mention "enforcement" in my editorial, I debated if I should use that term at all. I went ahead and included it to see what comments it would provoke. But, in my opinion, I don't think enforcement of any DBA code of ethics could be practical.
Instead, a DBA Code of Ethics should be a "guiding light," not an absolute set of rules. Perhaps instead of a DBA Code of Ethics, maybe we need a DBA Mission Statement that outlines what it means to be a good DBA. Again, this would not be designed for experienced DBAs, but for those who are entering the profession.
In any event, I am glad to see an active discussion of the topic.
Brad M. McGehee
DBA
February 5, 2009 at 12:32 pm
Ewan Hampson (2/5/2009)
Jeff Moden (2/5/2009)
The ironic part about this whole discussion is that a code of ethics would only be followed by ethical people. 😉Not the point. Having and briefing about a code of ethics should raise awareness - it's not an on or off thing, and you can become more aware of the ethical implications of a given situation, and realise you can do better. And having people signed up to a code makes it easier to show when they failed to observe it.
Understood and I agree... just want everyone to understand that a code of ethics will not make anyone more ethical. Most true DBA's follow a personal code of ethics that would make anything written down pale in comparsion.
--Jeff Moden
February 5, 2009 at 12:58 pm
Not to throw a wet towel on things but if that is the case why do SOX and HIPPA exist ?
They do, at least in part, to govern the tasks and responsibilities, not to mention, the ethics, of DBAs ...
now we are back to:
http://en.wikipedia.org/wiki/Association_of_Information_Technology_Professionals
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
February 5, 2009 at 1:38 pm
rudy komacsar (2/5/2009)
Not to throw a wet towel on things but if that is the case why do SOX and HIPPA exist ?
At the risk of being overly cynical they exist solely because politicians needed to be seen to be "doing something" about a scandal, without, of course, actually doing anything construcive. There are those who argue these acts are actually harmful rather than helpful.
And whoever spoke of irony in this thread nailed it. You can't enforce ethics--unless you have a large club with sharp metal spikes sticking out of it and spies hiding under the bed.
I'm all for checks and balances, audit logs and the like. I'd even go for a list of what's expected of a DBA in general terms for newcomers. But that isn't a set of ethical guidelines, it's a job description. 🙂
February 5, 2009 at 2:56 pm
Brad's comment about a mission statement, even one worded as a code of ethics, or vice versa, would definitely be of use to people new to the profession. Would definitely have been useful to me when I started out, at least if it were well put together.
For example, an SQL Dev might be perfectly able to write code that "gets the job done", but what if it's written at the cost of potential data corruption? I've seen that kind of thing in any number of discussions about "home brewed identity columns". If a new DBA/Dev had a "Code" or "Mission Statement" that made it clear that the first duty is protecting the data, that kind of solution might not be considered, and that would be a good thing.
My first priority when I started out was simply "can I get the data into the form, and get it back again when I need it next time". Didn't even consider the importance of table integrity checks, locks, etc. Maybe with something that outlined a few key basics of "the DBA Code" would have been useful. Instead, I've either come up with my own Code or borrowed from others as it became clear that they had something that was worth borrowing. (Kind of like borrowing code, but slightly different.)
In that respect, yeah, a codified or at least outlined DBA Code would be a good thing. Not so much for blame and punishment, but for education and clarification.
Of course, such codes always eventually mutate into rituals and traditions, and then somewhere down the line, someone has to make a movie where the hero wins by breaking all the rules and being either really cool or really hot or both at the same time. 🙂
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
Viewing 15 posts - 31 through 45 (of 50 total)
You must be logged in to reply to this topic. Login to reply