We’ve been doing it “forever”. As a developer, I was always fascinated with writing scripts and tools that made my tasks less mundane and error-prone. And running them is a joy… 1, 2, 3, and BAMMM!!!. 🙂

For any number of reasons, instead of writing a script, we do repeating “keystrokes and clicks”, which is fine because that’s how we use computers. But as soon as the task meets certain criteria, automation scripts make sense and can give you repeatability, speed, and fewer chances to make mistakes.

When to automate – criteria?

When the task is repeated many times.

For example, when you build a Windows Service application, you can add a pre-build and post-build scripts which can stop the installed instance, build new version, install the new binaries, and then start the service. Imagine, you need to do that every time you build your service… the script will boost your productivity and eliminate this mundane task.

When the task is long and laborious.

Let’s imagine you need to deploy 100 instances of the application to a server. You need to create 100 folders, copy the application files, apply configuration and so on… you get the picture. It’s laborious and only in my nightmares, I would do something like that manually. 🙂

When there is a great chance of mistakes when doing the task manually.

You need to recreate a database with test data. You write drop, create and insert statements, apply some data manipulation, and you are done. If you do that manually, you can run statements out of order, create a typo, copy-paste errors, … You lose repeatability and introduce mistakes in your data. Use SQL scripts instead :).

When the ratio between time to write automation vs. time doing it manually X times is less than 1.

It’s a simple calculation. If it takes you 1 hour to write a script and you spend 5 min to do the task manually, you quickly see that automation makes sense if you do that task a few times a week or even a day! Imagine time savings, when your teammates do the same. Also account for the time you spent debugging because of small mistakes.

Rules of thumb

• Make your scripts/tools idempotent (when run multiple times should produce the same result),
• use defensive coding,
• test scripts on a small scale before running them within a full scope,
• when writing database manipulation scripts/tools, pay extra attention to make them robust and safe to use,
• share your scripts/tools with your fellow team members in source control. You never know when someone might need a script you wrote.

Automation ideas

• Applying configuration between your application environments,
• installation/uninstallation of applications,
• calling HTTP API to configure or execute some process,
• generating mock data in the database,
• running functional or load testing of your applications,
• data anonymization,
• data migration,
• applying system configuration,
• …

The benefits that you get from automation scripts can vary. Apply KISS (Keep it simple stupid) and YAGNI (you ain’t gonna need it) principles when appropriate. In my experience, someone can learn a lot from the process of writing the automation scripts/tools. Not only technically, but also find potential problems and issues with manual processes and workflows. Last but not least, you can plug-in the automation script to the CI/CD pipeline! What about that! 🙂

Do you have anything to add? What would you add to the lists above? Let me know in the comments below.