When there is no automation, you do the work.
When there is automation, you work for the automation to do the work.
Whenever there is automation, the following work exists:
- Development of the automation tool.
- Learning how to use the tool.
- Collecting parameters to pass to the tool.
- Checking the state of things, before running the automation.
- Recording execution progress and outcome for investigation.
- Fixing things when the automation encounters an error.
- Cleaning up when things are no longer needed -- reduce resource usage / cost.
Common issues with defining and using automation are:
- Not handling all cases.
- Not knowing how long a process takes.
- Not understanding what an error means.
- Not knowing how to resolve an error.
- Unnecessary / repetitive waiting.
- Manually copying values between different automation processes.
- Starting an unstoppable process, then realizing something is wrong shortly after.
- Forgetting to clean up.
- Cleaning up, then realizing there is a mistake.
The impacts of these issues include:
- 🧠 Mental stress.
- 💙 Emotional stress.
- Loss of morale.
- ✊ Inefficient use of effort.
- ⏲️ Inefficient use of time.
- 💸 Inefficient use of money.
To reduce these negative impacts, an effective solution should encompass the following concerns / considerations:
- Low effort to prototype a hacked up solution.
- Progressive effort to turn the prototype into the actual automation tool.
- Compiler support for tracking execution paths.
- Automation based on psychology, not philosophy.
- Present information suitably for the current usage.
- Steps are executed with parallellism and concurrency.
As much as possible, the solution should shoulder the burden of development from the automation developer -- if developers can focus on business logic, and automatically receive the user-friendly features, then the development experience will not be degraded, which allows them to maintain visible output and provide good user experience.