The First Tiny Steps

A reader left a comment on Michael Hunters blog asking how one could develope into a SDET (Software Design Engineer/Test) when his day job does not have much scope for automation. Michael provides him a simple answer which says to make it his night job. heh!

Reading this makes me relate to a few days back when we were preparing the final validation documents for submission. Unfortunately I cant go into details till our press release but I'll talk about something very similiar.

As a new employee 2 months ago I did notice that no one is really a big fan of automation. Some places do not need automation but some places could do with automation. Unfortunately I had not been able to convince my manager to automate a few things I felt should be automated. But that didnt stop me from thinking up other ways to get his attention towards automation.

When we are making our daily runs/builds

• All programs lie in the PROGRAM folder.
• All Logs (of corresponding programs) lie in the LOG folder
• The outputs of the programs lie in the OUTPUT folder.
  
  

Fortunatly when we laid out the specs, we put forward a naming convention for the three. An example would be, for an output the corresponding programs and logs will be:
Program : ABCD 1.2.3.sas
Output : Table 1.2.3.doc
Log : ABCD 1.2.3.log

The final stages of our submissions process is something like this:
A folder is created for every set of program, output and log. This folder will be named the same as the output file, taking off the extension .doc. So our validation folder would carry another folder with the name Table 1.2.3 and this folder will contain the above three files along with other documentation.

Now the poor programmers (myself included) who wrote the programs are the ones responsible for making this folder with the above documents. So if you walk into a programmers office when he is creating this structure, this is generally what you find on his screen. Four windows of Windows Explorer open, having the program, log, output and validation folder. Then he searches through the list of programs and identifies the one he wants, copies it into the validation folder. Ditto for log and output. Then he realises he has to do that for another 80 more programs/logs/outputs... turns around, takes out his revolver and shoots you in frustration! After he is done with all the 80 folders someone comes and tells him they had got the numbering wrong and all the numbers need to be changed. He shoots himself.

So to stop myself and others from being killed, I came up with a small (but effective solution). Automate this process. Usually we work off SAS. Doing this through SAS might have taken a little more time (which no one had) but like Michael suggested, I made it my night job. A simple application in C# would not take more than a few minutes to bring about the desired automation.

The next morning I did a small demo before my manager. He was happy. 3 hours of work had come down to 3 seconds. The programmers were happy. Everyone was happy. But most important - automation had taken its first tiny step. Suddenly I had people come up to me and say - "Hey, can this be automated too?" - "If we can write a generic program for this, it can save us a lot of time" etc. I find myself much more busy, but much more satisfied! The programmers are smiling. They finally got to go home early! A very small 20 line program can change the way everyone looks at automation today.

So when your workplace does not really support automation - look around. Definitely there is something which could be automated. There always is. Even the smallest thing. Once it gets noticed, there is no looking back.

On a different note - most people in the pharmaceutical industry might not know much about C# but to my surprise not a single person at work had heard about it! My manager just walked in today and wondered about this other issue and if it could be solved better with C#. For everyone at work, C# = Magic! ;-)