Automation is a bedrock of software engineering. Tools, scripts, tests, and even reports are vital glue that keep projects progressing forward. Because time spent on automation generally detracts from product work, it is considered an investment. Sadly, more often than not I see an erroneous equation applied to determine whether the investment will be worthwhile:

(manual repetitions * time) - (time to develop automation) = value

If the value is positive, the automation is a green light. Otherwise, is it really a waste of effort? There are many factors not being considered.

Automation is less error prone.
Processes are put in place to account for human error, so why add another layer where humans can go wrong? Computers won’t forget to strip symbols before deploying or test a feature used by thousands of people. Automating processes adds a known and reliable security blanket so engineering can proceed with confidence.

Automation can be run any time, without humans in the picture.
Need test results at 11pm? No problem. Your build engineer is out with the flu? The latest revision has already been built! If you need 100 runs through a test plan in a day, the computer won’t complain. Automation is tireless.

Automation can be run at a high frequency.
Just as high frequency trading has changed the stock market, the ability to run scripts and tests more often can have a transformative effect on your processes. Having a packaged build always generated means others in your company can easily live on the latest bits or send one-off builds to users to make sure issues are fixed. Running unit tests on every commit will allow you to immediately pinpoint what code caused a regression instead of having bugs piling up. Older bugs are more expensive; it takes engineers more time identify and ultimately fix when they aren’t as familiar with the code. The same principal can be applied to higher level/UI tests and performance testing.

Automation can build on itself.
Writing an automated test is only the first step. Once you have tests, you can write infrastructure to kick these off. Then write tools to aggregate results. Next is generating reports. Complete the circle by automating emails of the reports to yourself and managers. Each step along the way may have a different return, but they are paved by the previous steps. This ultimately leads to an invaluable end-to-end workflow.

Automation is more fun!
Who rejoices in manual labor? Developing automation is a challenging activity and a great way to engage those on your team who have been burnt out by boring repetition. Each time a script is run, they’ll smile in knowing they’ve saved themselves time and work. This encourages even more automation to be written.

The next time a simple equation is levied against automation, be sure these factors are also considered. Of course, for some domains automation is not appropriate or prohibitively difficult. It is less flexible when encountering ambiguous inputs and falls down at doing anything ad-hoc. Automation must also be maintained and kept up-to-date. All said, from my experience the teams with effective automation setup are also those in the least technical debt and can be bigger risk takers.

To wrap up, please observe this discussion between an engineer and his manager:

Kirk: Scotty, progress report?
Scotty: I’m almost done, sir. You’ll be fully automated by the time we dock.
Kirk: Your timing is excellent, Mister Scott. You’ve fixed the barn door after the horse has come home.

Note, the manager now realizes the value of automating as quickly as possible!