Automation is the best answer, the more we automate the less human effort actions take. I am not going to say the less mistakes are made, as if the automation workflow has a error in the process then you have automated making mistakes.
For this post I am going to define automation as the simplifying of one or more process into a repeatable set of steps preformed by a user. Why does this definition matter? It has to do with the example that I will use through out this post.
If we define one we should define the other. A process is a series of action preformed in order by a user to achieve a repeatable outcome. These actions may have sub actions and can be repeated with in a process.
The Example
Lets describe the existing process first before we talk about the automation. As part of the managed services development work our team needs to create openshift clusters. These clusters have a short lifespan, only a few days. So we often create them. There are times we need to create clusters of different sizes and of different styles. Bash scripts have being shared for doing these actions and actions like checking if the cluster has being installed yet. Sometimes people will have two or three cluster on the go for testing reasons which means user understandable names to describe these cluster.
Over time the scripts have evolved and added new features, but not everyone has these newer scripts. This is the process that is going to be automated and by automated I am going to say development cluster creation actions added to a cli which is versioned and update-able. You might say that this is the same as having the bash scripts and you would have a point. Where changes is when developers need two or three clusters. Each cluster need a unique name and with the version for the scripts I have that means edit a json file each time. This is why I defined automation as simplifying one or more process into repeatable steps. The easier naming process is the set of actions being automated.
That's a high level of the process. There are other features that make this work worth while but they don't matter for the concept here.
Designing the automation
For my previous adventures with creating a cli, some of the learning's are outline in the post Git-grab, a side project introduction, I know that the best place to start is with documenting how to use the tool. With that in mind I worth the first draft, a outline of the commands I expected to have.
The next stage was to add more details to command in the order to that they would be used. This meant documenting each flag and added examples of the command is to be used. After this I would stub out that command in the cli. All the flags were there along with help text.
Designing how the user will interact with the tool is most important. Implementation is just a detail that the end user dose not care about. As developers that's the part we care about.
Knowing the process
From having to preform the actions may times in the past, I knew two keys points about the process. 1) The most common action to be carried out is creating a cluster and 2) tab completion is a most as makes the process so much easier. With documenting the design and how the user would use it first I knew there would be configuration required the first time a user used the cli. Setting up a default name and style of cluster created. The information that would be found in the json file.
The initial design had a command was called "configuration", which is a good name for a command that does configuration set up. But when we know that tab completion and cluster creation are the most important parts of the process, we know that a command "configuration" and "create" would be a conflict for the tab completion. With both commands starting with "c" the user would need to type a second letter to get tab completion to complete.
In this early stage knowing this meant it would be much easier to change the design. Now that the "configuration" command turned into a "defaults" command which works differently to the originally document concept but not implementation details had to change. A design note has being created which states no command can be added that starts with "c". This is to help not break workflows for users in the future.
View on automation
Automation is extremely powerfully but hard to get right. As I said at the start if you automate an existing flaw in a process, you have just become better at making a mistake. The next thing to think consider is once its automated, it becomes harder to change the process. When I say harder to change its for the same reason the design note was created about commands starting with "c". Once this cli is in users hands, even my own, in a short time the muscle memory of pressing c, tab then enter. Any change that affects this workflow will upset the user.
The less we know about the process the harder it becomes to automate. Where this really affects things when your trying to be fresh and bring a new idea to market. Image trying to bring a service to market which is to save companies time doing X tasks. If the process design is not correct, it wont matter how well it was implemented. Customer wont use it.
Implementation is not worth much. Yes bad implementation can cause bad automation but even the best implementation can cause bad automation if the process is not correct. The process design is where the real gain from automation is decided.
I am not saying that we shouldn't try automate things, I actual want to say we should automate everything. What I am saying is automation is not easy and we need to know the correct process so we don't automate our mistakes.
