97 Things Every Programmer Should Know

Chapter 78. Step Back and Automate, Automate, Automate

Cay Horstmann

I WORKED WITH PROGRAMMERS WHO, when asked to produce a count of the lines of code in a module, pasted the files into a word processor and used its “line count” feature. And they did it again next week. And the week after. It was bad.

I worked on a project that had a cumbersome deployment process, involving code signing and moving the result to a server, requiring many mouse clicks. Someone automated it, and the script ran hundreds of times during final testing, far more often than anticipated. It was good.

So, why do people do the same task over and over instead of stepping back and taking the time to automate it?

Common misconception #1: Automation is only for testing

Sure, test automation is great, but why stop there? Repetitive tasks abound in any project: version control, compiling, building JAR files, documentation generation, deployment, and reporting. For many of these tasks, the script is mightier than the mouse. Executing tedious tasks becomes faster and more reliable.

Common misconception #2: I have an IDE, so I don’t have to automate

Did you ever have a “But it (checks out/builds/passes tests) on my machine?” argument with your teammates? Modern IDEs have thousands of potential settings, and it is essentially impossible to ensure that all team members have identical configurations. Build automation ...