Some of the most important best practices in software engineering deal with automation; automated builds, automated testing, automated backups etc. It seems that developers are obsessed with automation, but why? Is it because they are lazy? I think there is something to that (and that’s a good thing, laziness being one of the Three Programmer Virtues), but I think that the main reason is safety. Automated processes have fewer errors.
Computers are really good at certain things, and one of them is doing the same task over and over again without variation. If your build process is ten steps long, and automated version will ALWAYS perform those ten steps. It will never forget a step and cause error down the line, and if one of the steps fails for any reason, it will stop and hopefully inform someone.
Because of this, I feel that every developer should be familiar with writing scripts. They can be shell scripts, Perl, Ruby or whatever. They just need to know how to create scripts for turning error prone, slow and tedious manuals processes into fast, easy and error free automated processes. In fact, I would feel nervous about hiring a developer that either didn’t know how, or feel the need to created automated scripts from time to time.
I also have found that this rule of automation is and should be applied to process outside of software engineering. Rules to filter your email are an example of this. The power of automation is what makes macros (properly used) in Microsoft Office and the Automator tool on OS X such important tools. With these tools the average user could, with a little time, automated those painful tasks, saving themselves time and preventing errors.
I will be from time to time providing examples of things I have automated in my own work and of how you can automated common painful tasks that every one seems to deal with. Keep an eye out for it!
Andrew - this isn’t automation in a programming sense, but lifehacker has a lot of ways to automate things in your daily life: http://lifehacker.com/tag/automation/
I use quite a few of these - esp the defragging and downloading files.
One word sorely missing from your post is “efficiency”. Having an email filter sort my email for me isn’t nice because I’m lazy or because it’s safe. It’s because it saves me time and makes me more efficient.
I could sit and rearrange the files on my hard drive manually to defragment it myself but my time can be much better spent doing other things. While (automated) defrag is running, I may have 5 or 10 or 40 other automated processes running and still have a solid 40 hours a week of work to complete.
1 person completing the work of 1/4th a person is probably being lazy. 1 person completing the work of 4 people is something completely different.
Troy,
I agree that efficiency is a big reason. The good kind of laziness I am referring to is basically a desire for increased efficiency. I don’t want to spend time doing all those tedious tasks. So I automate it so I don’t have to do something that I hate. That is what I meant by laziness being a programmer virtue.
The safety factor is something that I think needs to be addressed though. There are processes people will tolerate being manual because automating them would take some time and they don’t want to bother because they are not done on a day to day basis (bad kind of lazy) and error occur in those process frequently. Automation can eliminate many of those errors.
In my mind efficiency is not just about 1 person doing the work of 4. It’s 1 person doing the work of 4 with no loss in the quality of that work. Efficiency is both more faster, as well as more correctly.
I’ve had experience in this in software development. In my old company we had a manual deploy process for new releases of our web app. It took a long time, yes. But we at times forgot a step and would as a result have a bad deploy. This would result in wasted time for me, but also downtime for the site, which is bad. When we automated that process those kinds of errors went away.
I would also argue that the defragging example you gave is not the kind of automation I am referring to. That tool is present mostly because you cannot manual rearrange the files on a fragmented drive in a way that would defrag them. Other automated operating system tools are there so that you computing experience is less about operating the computer itself and more about getting your work done.
However, where automation can come in handy is when you have an existing workflow has many, many manual steps. By automating these steps, you shorten your workflow, and decrease errors.
Just a quick comment about the automatic background defragmentation issue: it’s extremely convenient, compared to the hassle of running manual/scheduled defrags on a large number of workstations. It reduces the IT personnel’s workload substantially if the servers and workstations can manage atleast this aspect of system maintenance on their own. Less manhours wasted = more $$$ savings, so it’s the best option in a corporate environment.
PS: By manual/scheduled defragmentation, I don’t mean that the user rearranges the file fragments on the disk manually, but that the defragger is of the obsolete, resource-hogging ‘manually-run-and-wait-until-it’s-done’ type.
Martin,
I agree, that is in some way the kind of automation I am talking about. But I am more focused on the workflow people have that is so custom to them they haven’t been automated by the OS already. That is the kind of automation that people need to do for themselves.
Hello people,
Can you give me some more info about the CAD automated testing languages? I used to use TCL script. But I would like to know more options. As I have seen in this blog there are many speakers knowing many things about automation, i thought this is the place to know about the CAD automation!!!
Thanks
Monalika