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.