Plan and Prepare or Just Do It? How about Both!

BuckWoody — Thu, 07 Jan 2010 15:56:00 GMT

I'm kind of a type "A" person. OK, I'm a VERY type "A" person. I even cook by setting things up ahead of time. I'm definitely more in the "Plan and Prepare" camp than the "Just Do It" camp.

But I do realize that there are times when you just can't stop and prepare. Sure, it would be great to know that server is going to melt down just now, but it happened and you have to deal with it. Now is not the time to open the plastic on that "Troubleshooting SQL Server" DVD course you bought! You just have to dive in and get the thing fixed.

Hopefully you're not operating like that all the time. If you are, you probably need to get some help with your systems, at least temporarily, until you can get them stabilized.

So which is it? Should you be like me, a type "A" who has to have everything planned out, or a reactionary agent, fixing things as they happen? How about - Both!

I think you should aim to plan and prepare as much as you can. Your life will be more stress-free, and you'll be happier in your job. But you can't lose your head when things go wrong and demand time to plan and prepare. You just have to jump in there and fix the problem.

But I think there's a happy medium in there somewhere. I ten to plan and prepare for the times I have to "just do it". I have my scripts ready for things like backups, DBCC repairs, restores, web site links for "how to" articles and so on. I have those right by my desk so that I don't have to panic when panic hits. So in effect, I'm doing both - I'm planning to just do it.

Knowledge is how you break the rules

BuckWoody — Tue, 08 Dec 2009 13:55:00 GMT

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.

Buck Woody : SQL Server, Disaster Recovery, Process

Plan and Prepare or Just Do It? How about Both!

Knowledge is how you break the rules