Automation FTW

One of the things I often discuss with other developers is how little (on average) we automate our work-related tasks.

Think about this. We make our living automating our users' activities:

• We write applications to replace manual processes.
• Our programs send notifications so that they users don't need to waste time checking for process status.
• We make our programs talk to each other and to third party systems so that the slow and expensive human interaction is avoided,
• In more general terms, we go through great lengths to ensure our users are adequately empowered and hopefully more productive.

Contrast that to the way we historically see developers conducting their daily chores.

• We often work with incredibly powerful IDEs or text editors with macro support or even an extensibility model. When was the last time you employed a macro?
• How many times will that manager will have to send you that updated Excel spreadsheet or CSV file until you write a script to verify each line instead of the tiresome and error-prone manual check you have been doing?
• Aren't you tired of keeping track of which files changed since last time you updated the application? Have you ever thought your Source Control Management tool could make this much simpler?
• Are you kidding me? You're writing that same SQL query for the Nth time? How hard is to save this query for a change?
• If your work cycle looks like this: Save, Build (wait), Debug (wait), Click, Click, Click, Type, Type, Click, Verify result, OK;  someone needs to introduce you to a unit testing tool immediately.

I'm as guilty as the next guy of falling in one of the the above anti-patterns. The way I found to make these traps the exception, not the norm, was to make them less comfortable than the automated alternative. The key in the entire process is lowering the automation entry barrier by learning. It also helps if you cultivate a positive attitude toward learning.

Here's my laundry list of steps to make those CPU cores earn their salt and leave my own processing power for more challenging things. I have some of these items pegged but I'm not done with all of them yet.

• Take the time to explore and learn the capabilities of your IDE/text editor. Find a cheat sheet and print it. Learn one or two interesting keyboard shortcuts every day. Learn how to write/record a macro, it's usually so easy that you'll be ashamed you hadn't done that before. Some tools even have strong user communities sharing macros. See how your IDE can be extended, if it's beyond your reach, maybe there are third party productivity add-ons that will boost your productivity and pay for themselves quickly (if not already free.)
• Other applications, like MS Office apps, also have a rich extensibility and automation model behind them. If that application insists in being part of your workflow, investigate how you can show it who the boss is.
• One of the best things I've done in the recent years was to add a scripting language to my toolbox. I highly recommend that. If possible pick a scripting language that is reasonably different from your primary development language, it will make the learning phase more interesting. I'm currently working with C#, so I thought Ruby would be an interesting language for scripting tasks, and that's what I use most of the time.
• Be adamant about using your SCM as part of your deployment process. Learn how to do labeling/tagging, diffs, updates, etc not only using the GUI but also through an API or the command line. You'll be writing scripts against your SCM in no time and the weight of tracking changed files will be lifted.
• I tend to include a tools directory within each project directory structure where I keep (among other things) all the scripts I create to assist development and maintenance of the application. These files can be SQL scripts, Ruby scripts, .bat files, and anything that can be repeatedly executed. Some scripts turn out to be generic enough that I keep them in a common location, such as c:\projetcs\tools.
• I won't attempt to get yo hooked on TDD or Continuous Integration here, that's something for another day. I will say, though, that if you don't already use an automated unit testing framework, you owe yourself a closer look into that. Why write several test applications or run the entire application all the time to manually verify that everything still works when there are tools to automate this? Take a look at JUnit/NUnit (the xUnit family), RSpec or whatever there is in your language of choice.
• No text about software development automation would be complete without at least mentioning build automation tools. Tools like Ant (NAnt), MSBuild, Make, Rake go a long way toward providing complete solutions for automating the build, testing, packaging/deploying of an application. Very few things are more satisfying than executing go.bat and seeing your application being compiled, configured, and tested in a fraction of the time that it used to take when you did all this manually.

As many things in life, the hardest part is getting started. Once you have your first one or two tasks automated, you will be more aware of tasks that can be automated and you will be more confident that you can indeed automate this task that you were just about to start for the second time.