Recently Adam chimed in on a list we are both on with a link to the best practices (Rules) around setup and I realized that even if you know a topic well you should go back to the well from time to time to ensure you are still on the right path. I think back to the days when coding by stringing together user input to make a SQL statement was accepted as the way to build a login form (before the first SQL Injection attacks). You have to seek out other sources even (maybe especially) on things that you hold yourself to be an expert with. I now find myself reviewing how we do setups at DTS to make them better and finding Adam’s advice to be a very good source of points to contemplate.
Paul Randall has a compiled document with all his blog posts on SQL Myths that I think is a must read if you consider SQL Server part of your core competence. It is probably not very interesting to pure devs, but I would still suggest you take a scan of this so you can avoid making assumptions that are either out of date or just plain wrong.
Find the link to the PDF here: http://www.sqlskills.com/blogs/paul/CommonSQLServerMyths.pdf
We have a saying in the various companies with which I associate and it is “Any fool can manage success, but it takes talent to manage a crisis”. The leader, project manager, team leader, or whatever you call the person in charge has to not be wishful. This sounds easy, but in my experience it is one of the hardest things to do for any individual. We tend to be hopeful and that is the slippery slope / gateway drug to wishfulness.
The reason I say this is that my own biggest screw ups are almost all tracable to some point in the past where I assumed that something would happen more positively than it actually did. This sounds like the classic admonishment against assumption and to some extent it is, but wishful is more of the root cause and assumption the symptom.
As an infantry platoon leader in Iraq many years ago, I learned that you are never done planning for and defending against the things that can go wrong. When you envision contact with the enemy it is easy to expect that things will follow the simplest route and flow like water, but since there are humans involved this is highly unlikely to be the case. You might even get lucky and survive this way once or even twice, but that just means you are more likely to get killed when your luck runs out. I try to run projects the same way. What if the components that should work fine together don’t? What if the client changes the deployment server to run a 64 bit OS instead of the 32 bit OS on the test server? What if there is an illness or death in the family of my key developer the week before delivery? You can drive yourself crazy with these things and I am here to say that you should. That is the job.
The first place to start is by making plans and schedules with milestones. If you are collaborating with others it flushes out wide variations in viewpoint quickly. Either I accept your timeline or propose another (assuming I am not totally whacked). If I propose another you might discover that it just won’t work early enough to do something about it. I have seen good resources fail to deliver items well within their ability due to time wasted assuming everyone has the same, sane view of what needs to be done by when.
And to top it all off if you follow this advice and try to plan for all possible outcomes, there will still be surprises and things that you did not count on which is good because otherwise we could write a program to replace your part in the show…
Michele Bustamante and I have started recording the first episodes of our new security focused podcast LockDown. While the website is up, it has place holder content describing Carl Franklin of .Net Rocks fame as our first guest (that was the original plan). However as usual Carl was flying around the globe when we started and we all agreed to save him for later.
If you are interested watch the podcast url or my blog (here) for the first show when it releases.