A community of more than 1,600,000 database professionals and growing

Today we have a guest editorial from Andy Warren as Steve is traveling.

I imagine most of you have heard the bit of wisdom that says "use the right tool for the job". I think generally that's good advice, but perhaps not applied as often as it should be. Sometimes it’s because we don't recognize the problem as having a particular type of tool that applies. Sometimes it feels like overkill to get the "right tool" either due to cost or because it will only be used once. Sometimes it's because we're not comfortable learning a new tool or worry that we'll spend more time trying to master it than we get back in productivity. I've fallen into all of those traps more than once!

I made a note to write about this after wrapping up a project recently. I work for a small company on a small operations team. We don't usually take on projects that span months or have a lot of dependencies or need down to the minute planning. Trello (or anything in that class) combined with a weekly meeting works well for our needs, though sometimes we'll have a spreadsheet with details or a rough outline. Informal and effective - for our usual work.

The project was a colocation facility to cloud migration. Over the course of months we marched along to our plan using the tools we usually use. When it was time to plan the actual switchover, we started listing tasks in the spreadsheet and that still worked well. Until we got to the point of determining how long we expected to take during the planned outage window. We put in the tasks, rough estimates on the duration of tasks, and then hit the wall when we needed to see what work could be done in parallel. It's not that you couldn't figure that out in a spreadsheet, but was it the right type of tool?

I proposed using MS Project because it's designed for that type of problem, and I had used it just enough to think it wouldn't cost us a lot of time to move to it. The team didn't respond with enthusiasm. Using MS Project for a plan with 80 or 90 tasks? MS Project is for, well, big stuff! I loaded up the task list and at the next planning meeting it took everyone about two minutes to realize that yes, this is better. Not much different than a spreadsheet for entering tasks and you get a lot of extra capabilities.

So at that point we were (arguably!) using the right type of tool for the job. But was it the right tool? For figuring out the plan it worked fine, but we were trying to plan tasks that in a lot of cases had a duration of five minutes or less (shut down this service, confirm this matched, etc) and we couldn't get Project to show it quite as well as we wanted in a gantt chart.

As we continued to plan we knew that we'd need to have multiple people making edits for a while, that we'd need to put the live view up on status monitors, and that trying to get everyone using Project was one more thing to do. With the plan pretty much in place we spent a couple of hours looking at web based alternatives and found several that would import a Project file and of those one that was both pay as you go and had just the gantt view we wanted.

We'd gone from a tool to the right type of tool to the tool that best met our needs. Good stuff.

Join the debate, and respond to today's editorial on the forums

Functions overloading is not transparent in the SQL Server's implementations and can cause some confusion. The rule of thumb, which is not found in the BOL, is that the input data type directs the overloading, something that is rather obvious when one comes from a procedural background but not for any newcomers to the set based platforms. Haven't found solid references yet so feel free to contribute!

Ref: Replicate - click here

» Discuss this question and answer on the forums