A few years ago, the company that I worked for was preparing to upgrade from MS Sql Server 2000 to Sql Server 2005. While there wasn't too much abnormal concern about upgrading the databases themselves, there was a lot of concern about the large number of DTS packages that the company created for the majority of their B2B processes. Their solution until they could come up and complete a test strategy to ensure the DTS packages would run under Sql 2005's DTS runtime, just incase the packages couldn't be converted to SSIS in some fashion, was to stop writing new DTS packages and push the processes into .Net console applications that would be scheduled through a batch processing system. Personally, I liked this solution since it allowed me to write .net code in VS and not VBS code inside of the DTS Package designer in Enterprise Manager. Actually abstracting out processes into a more reusable and testable state was a great benefit over VBS and DTS as a whole.
One of the first console applications written under this initiative was to automate a series of manually ran Sql Scripts that people were running against production to accompany a file import process. It was a pretty simple project and ran, still to my knowledge, bug free, even when tested by my QA team.
Now fast forward to today. The need for the process is still in place and the code hasn't been updated since no changes have been required; however, I found out that the application was only ran once in the past few years and then the person who used to manually go through the steps and scripts didn't want to automate it and has been doing the manual steps ever since. Even today, this person has continued to manually spend a few hours every other day going through the same ceremony. I think my brain gave me a BSOD from what I find highly illogical thinking.
So I approached my coworker who has been doing this and start asking the number of "why" questions I had. Here are some of the responses I was treated to:
- "I don't trust what I cannot see or watch."
- "I like being able to watch and correct where necessary."
- "The process had a bug."
- "I won't ever know when it breaks or succeeds."
- "What else would I work on?"
From the discussion around these themes, there are a few design and development themes that can/should be implemented when faced with such an anxious coworker.
Establishing Trust through Quality
While I see James Bach's point in his "Quality Is Dead" blog post, I disagree with the blanket of the statement. There are always constraints when you're talking about software development (usually Time/deadlines being the largest constraint), it doesn't mean that every piece of code that you churn out will be of poor quality. Practices such as TDD or just plain Unit Testing and reporting can be implemented in order to demonstrate and achieve a higher level of quality to someone who doubts quality. Now, I believe that any developer can write code with and without unit tests and still achieve the same level of quality; however, it's easier to validate that level of quality through unit tests and TDD practices. This level of validation is essential to people who do not trust something to be automated.
Establishing Awareness through Instrumentation
The bulk of the other themes that I received surrounded the concept of being able to step through the process and watch/correct the data as necessary. This is a nice thing for debugging; however, if an automated process has to be stepped through, then it's not automated. One way to handle this issue is to ensure you have a high level of coverage of instrumentation in the code/process. This means making sure the proper types of notification is provided, auditing is turned on to the degree needed, and any errors (be it bugs or bad data-related) are captured and reported appropriately. I cannot confirm my coworker's claim that there was a bug in the code since I was unable to find one in the bug database. If an email to capture the error existed, at the very least, I would begin having my own doubts about the quality of the code; however, even that was not found. If instrumentation was implemented to a better degree than what I put into it for error logging and tracking, I would be able to verify the claim. As far as bad-data and catastrophic scenarios (i.e. server loses network connection mid-process), those items can (and was) implemented through logging or some for of process auditing infrastructure. The more data that can be provided, the more confidence the person will have when automated.
Establishing Automation Can Assist with Workload
The last theme that came from the conversation dealt with how the person's routine became. This person was a very routine-oriented individual who knew exactly when to do when and how long it would take. This person was a person of ceremony and possibly a bit fearful of being automated out of a job. After being in the industry for a number of years, I have came to the conclusions that those nightmare stories of people being replaced by programs rarely happen to the developers or analysts that implement the program or automated process. The automation allows for new, different tasks to be done. Even if the automated process is kicked off manually, it still frees up time to do other things. This means you can do more easily or in general transition onto the next big thing. I do not really know any company out there that would say they have a truly shortage of work. Even if it's wish-list, lowest priority, internal cost projects, there's always something to do.
Summary
Automation is a beautiful thing that I have grown more and more fond with. I have grown into a developer where I look for things to automation. I have seen the themes I talked about here at a couple of different companies I've been with and people that I've talked with. Each time, I find more and more ways to automate certain elements of a work day and also make the work flow easier. Hopefully a few things here will help others as well. Now if only I could find a way to automate my chores at home. :-)
No comments:
Post a Comment