Last night I had to do something on a production system that you're not supposed to do. It's not important what I did or where I did it, but I will explain why I did it. A friend was in a situation where it was either "break the rules" or lose the system. So I did what I had to do, with lots of caveats and explanations on why this was a bad idea. But the key to being able to do those things was knowledge - I knew how that part of the database engine worked, and I knew how the application was getting to the database. That's the key to being able to break the rules - I knew what they were about to begin with. At the risk of sounding like a big geek, I'll point you back to the "Matrix" movie:

Morpheus: "Do you think that's air you're breathing?"

So this exercise drove out two keys for me:

1. The rules are there for your protection.
If the person I helped had followed the rules in the first place, we wouldn't have had to break them. Follow the best practices, pay attention to Microsoft when they say to apply a patch or do things a certain way. Those things were put there because the team that wrote the software and countless other cusomters thinks that's the best thing to do.

2. You can break the rules only when you completely understand why they exist.
This is the most important lesson. Unless you know what the rules are for, in detail, and the background of that detail, don't break the rule. Once you understand the reason for the rule - I mean really understand it - you can bend it when you have to. And remember, whenever you do this, there are usually consequences.