“If it ain’t broke, don’t fix it.” Let’s face it, we all live by that more than we should. We’re busy and it’s the problems people are complaining about that get all our attention. We rarely have the time to go back and improve our routines or redesign them. (Which is one reason I insist on taking the time to plan and try to do things right the first time, but that’s another story.) And sometimes, if a process is working, we don’t even think about what it’s doing – we just know it runs fine and has been for months or years. It never even dawns on us to question how it works.

Let me tell you a story that perfectly illustrates this: Ever since I learned to drive almost 3 decades ago, I had been keeping my car keys in my left pants pocket and my wallet in my right pocket. To get into my car, I’d get the keys from my pocket with my left hand, transfer them to my right, unlock the car and start it. When parking, the process was done in reverse – shut off the car with my right hand, get out, transfer the keys to my left hand, and put them in my left pocket. I don’t know why I started doing things this way (I suspect it may be because I’m left-handed), but that was just how I always did it, so I kept doing it that way. About 2 years ago, it stuck me – I was doing a lot of unnecessary shuffling of keys. If I just switched the location of my wallet and keys in my pockets, I could use my right hand for everything key-related. That resulted in fewer steps, less dropped keys, and made things easier when I had my hands full.

Many times, our SQL scheduled jobs are like this. They perform tasks without failing and we don’t think about them. As we migrate servers, we blindly transfer the jobs and make sure they run, without really looking into what they do. Sometimes, the job may be part of a bigger process that different people have worked on and no one has a clear picture of all the steps involved. I recently discovered a process here like this. There was a SQL job that imported data from a text file into a database. The text file was generated each week by someone in accounting, who made it by exporting a report from Crystal Reports. We had the opportunity to revisit this process for another reason and discovered something surprising – the Crystal Report was pulling data from a database on the same server we were later importing into! We quickly realized we could eliminate the middleman, and a huge source of potential error (we had had problems in the past with the text file being saved in an incorrect format), by simply taking the query the report used and incorporating that into our import routine. Now, the routine pulls data directly from one database into another with no intermediate text file or human intervention. That means better reliability, which means fewer calls to me to fix a problem. And I’m all for that. I have no idea why it was originally designed this way, but by taking a fresh look at it, we were able to rebuild it and take a chore away from an accountant who has better things to do. We later found 2 more processes that did the same thing, freeing up even more time for the person.