Chris Shaw (blog | @SQLShaw) brings us T-SQL Tuesday this month. His topic of choice is “A DBA’s Ethics”, which is a pretty deep subject! I feel like this post goes off the rails a little bit compared to the direction of the invitation post, but I had something happen last week that really made me think about this topic in a specific way.
NPR to the Rescue
See, I wasn’t even sure if I was going to write a post this month or not. I wasn’t sure what I wanted to talk about or if I was even going to be able to get enough coherent thoughts together. But then, one day last week, I was minding my own business (more or less), driving home from work, listening to WPLN, as I am wont to do, when this story came on. To very roughly summarize for those not interested in spending 18:34 listening (I do recommend listening to or reading the story):
- Father is upset as his son is convicted of bank fraud.
- Asks younger son to promise to never get into that kind of trouble.
- Younger son promises.
- Younger son starts own business.
- Realizes one day company is under water.
- One thing leads to another and 22 years after The Promise, said younger son is convicted of same crime as older brother.
I was interested in where this story would go… I mean, why do otherwise “good” people do “bad” things? At the beginning, I thought that somehow research was going to say that doing bad things “runs in the family” (the older/younger brother angle). As the story progressed into the part where Toby Groves begins asking employees to help, and they agreed, I started to think about how there’s no way I would do such a thing…and how could these people?
When the story got to its punch line, it made me think about how this topic related to DBAs:
We like to help each other, especially people we identify with. And when we are helping people, we really don’t see what we are doing as unethical.
A couple questions developed in my head when I heard it, and as I thought about it more, the questions only got more complex:
- Are we, as DBAs (or DBA-type folks) at all immune to this type of thinking?
- Would a DBA be more willing to help another DBA specifically? If so, how thin can we split that hair?
- What about supplying data for audits? Does that change the thought process?
- Does having an ethics statement really do any good?
I don’t have answers to these questions—not sure anybody does—but they make for interesting things to think about.
If Only I Had a Psychology Degree
I know the first question I have listed there seems pretty pretentious, but I wound up there due to specific reasons. Of course DBAs like to help other people; that’s not what I’m saying. What I am saying is weighing “helping people” while still operating within “the rules” is kind of what we do. I’ve spent a fair amount of time working directly with developers both on projects and to get projects deployed to Production systems. Although it is nice to be able to tell coworkers “that’s all OK”, that isn’t what we get paid to do; instead, more often than not, we’re paid to say No. Not because we don’t like people or enjoy it, it’s because we are trusted (there that is again) to apply “the rules” objectively to everything we are involved in or are supposed to approve for deployment. These “rules” can be administrative procedures, architectural/design policies, or even something simple like scheduling. Because of the nature of what it is we do, we are used to taking a step back, away from the people involved, to ensure that we do the right thing.
Does making decisions like that on a day-to-day basis make a person able to apply that same objectivity to every situation they ever encounter? Who knows? What about if the situation was changed a bit? DBAs (and sysadmins, for that matter), tend to rag on developers a little bit; usually in a good-natured way. But, I believe that, for the most part, DBAs and Developers are fundamentally two different kinds of people—we tend to think and act differently (and that’s OK). So, what happens if a fellow DBA comes to us with a problem or the results of a mistake and are looking for a way to fix it quietly or sweep it under the rug? Since we identify with the fellow DBA more so than, say, a developer, are we more likely to go along with the cowboy fix, as is pointed to by the study in the NPR story? I mean, if one doesn’t truly stop and think about what is going and what is being asked of them, it’s easy to simply think, “oh, Jim-Bob’s a DBA over on the Production team, surely he wouldn’t want to do anything outside of policy…”
What about the audit situation? This can go both ways: on one hand, one wants to help the auditor do their job by getting them the data they’re asking for. On the other hand, you may be wanting to help your team (or yourself!) out by possibly not supplying everything involved in a request. It’s easy to sit here and office chair quarterback the scenario, but that’s the point—it’s easy when you’re not in the situation yourself, in the same mindset (or lack thereof), staring the same consequences in the face. Thoughts and actions only count when…well…when they actually count.
This is where doubts about ethics statements begin to creep into my head. It’s easy to read through SANS’s Code of Ethics that Chris pointed out on this fine Tuesday and laugh, being like, “yeah, like I’d ever knowingly hurt someone’s reputation or look up the boss’s salary in the HR DB.” The problem is that opportunity or request might not come up on a Tuesday morning while we’re sitting around reading blog posts over our second cup of coffee—it might come up while you’re having an exceptionally bad day, and all you want to do is make at least one person happy. Before you know it, you might have gone off and done something illegal, or at the very least, ethically questionable.
Does having a company, community, or personal code of ethics keep this from happening? The way I interpret the reported study’s results, I would have to say no. Of course, that’s not true for everyone or every situation—it depends! It depends on a lot of things. So many things, in fact, that it’s completely within the realm of possibility that having such a code and reading it regularly to remind ourselves of the covered items could just cause the right synapse to fire in the right situation to keep us from doing something stupid. Does that make it worth the effort? Probably.
I have to say, though, historically, I’ve gotten crabby about things like this that get formalized. I always ask “Really?!”, because I feel like I’m pretty hard-wired in this department and get a little offended by having a code of ethics thrust upon me. I have to say that I’m a a little afraid after hearing the NPR story that there’s a chance I would let things get out of control before I realized what’s going on. At the same time, though, I realize that having that fear and being alert to it is probably about the best way to safeguard against doing unethical things in the first place.
There’s still a problem here. The problem is that we’re not perfect. Insidious things creep in at the corners without us noticing. Even though we’re trained and practiced in recognizing when something abnormal is going on and to see through the glossy surface down to the gritty details, things can still go horribly wrong due to being stuck in those details and missing the big picture.
I don’t know about you guys, but that NPR story freaks me out a little bit. Do I believe what I said above, about DBAs being used to making similar decisions, makes us immune to this type of “sympathy think” (pardon me while I make up words again)? No! I’m worried I go around every day a hair’s breadth away from starting something highly unfortunate just because I wasn’t paying enough attention or thinking the right way about a task.
Sure, talking about a DBA’s ethics is a little bit different than talking about mortgage fraud, but the fundamental decision is the same: Could what I am about to do hurt myself or someone else? It’s hard to think about that question at every turn throughout the course of the day, but apparently we need to, because once again, our animal brains are being a pain in the butt.