Rant: Applying Common Sense in IT

, 2012-08-23 (first published: )

Common Sense...

I was watching a training video last night and the instructor made the statement we hear all the time:

"Test this in a non-production environment before you make a change in production."

In fact, he repeated it several times. In a recent article I wrote, I included the following warning:

 The nmap tool is often considered a hacking tool by organizations. If you're going to use this tool within your organization, make sure you have permission to do so by someone who is actually authorized to give you that permission. In alot of organizations, the DBA manager does not have this permission. It usually falls to a security or networking manager to authorize this. When you do get said permission, make sure it is in "writing." Email is fine. You don't want to go on verbal permission. If something goes wrong (you're in IT, so you always plan for something to go wrong, or at least you should be) you want to be able to show you had permission to do what you were doing. Failure to get written permission from the right person can lead to what we call a "career altering event." Avoid this by doing the legwork to get the permission.

Then I stopped and asked the question, "Why do we have to issue these warnings?" After all, we're in IT. We work with systems that apply a strict set of operational logic in a particular order based on what we tell them. We often lament about end users who do very illogical things. So why do we continually have to provide others with warnings about testing something before rolling it into production or about getting permission to run a tool that could be seen as a hacker tool?

The short answer is because we probably aren't thinking as much as we should be. Before we do something we're likely not asking ourselves the implications of what we're about to do. Or we're so rushed to get something in that we don't have time to give it some serious thought. Computers allow us to work faster, but we shouldn't let that cause us to work too fast. We need to slow down. We need to understand what we're doing and why we're doing it. But we don't. And when we don't is when we make a mistake we could have avoided. We bring down a server we shouldn't have. We delete a database because we weren't paying adequate attention.

We also need to insist upon common sense and logic be applied by our IT co-workers. One does not roll something into production without testing first. One does not go on the first article or blog post hit in Google/Bing. Things like that. I think if we did, end users would have more confidence in us. And we'd get more done.





Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.


1,567 reads

Networking - Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I'd like to talk about social networking. We'll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let...


1,530 reads

Speaking at Community Events - More Thoughts

Last week I posted Speaking at Community Events - Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I've got a few more thoughts on the topic this week, and I look forward to your comments.


360 reads