Xebia Essentials : Craftsmanship : Three strikes and you automate

Mohit Kanwar
Jun 15, 2020 · 4 min read
Automate or not to

I am a passionate software developer who has been writing code for over a decade now. I love writing code. The idea of controlling a non-living machine by some keystrokes excites me. While I am young in this industry myself, I have seen tremendous growth in the software industry both scale and feature-wise.

I write code to solve business problems. I write code that helps me write code. I write code that validates the code written by me. I write code to understand concepts. I write code to analyze stuff. Anything that I find boring to do manually, I make it exciting by writing a code for that. I find repetitions boring.

I have been writing code to reduce my day to day efforts. E.g. one thing that I am glad that I did was I created a command-line interface (CLI). I use this CLI to do some quick tasks that otherwise will make me spend a few minutes. Some of the tasks that this CLI does for me are managing the environment for development.

I work with different projects having different environment requirements.

E.g. some projects still need Java 8, while for some projects I would like to use the latest Java version.

Some of my projects use different maven repositories that are licensed. Using incorrect maven repository settings with a project can sometimes lead to complex problems.

The CLI that I have written takes the name of the project that I want to work upon and sets up the environment for the same.

mycli env project1

sets Java and Maven according to project1

mycli env project2 

sets Java and Maven according to project 2 also starts the database

A simple example of the above script is as follows

#!/bin/sh
# setting up some local variables makes it easier for me to modify the script later on
alias j13="jenv global 13.0.2"
alias j8="jenv global 1.8"
# $1 in below line represents the first command line argument
if [ "$1" == "personal" ]||[ "$1" == "-p" ]; then
echo "Setting up environment for $1"
#Invoking the alias
j13
echo "Set Personal Maven"
# copy personal maven settings
cp -f ~/.m2/settings-personal.xml ~/.m2/settings.xml
elif [ "$1" == "xebia" ]||[ "$1" == "-x" ]; then echo "Setting up xebia environment for $1"
echo "Set Java 8"
#Invoking the alias
j8
# copy xebia maven settings
cp -f ~/.m2/settings-xebia.xml ~/.m2/settings.xml
elif [ "$1" == "myproject" ]||[ "$1" == "-m" ]; then echo "Setting up myproject environment for $1"
echo "Set Java 8"
#Invoking the alias
j8
# copy myproject maven settings
cp -f ~/.m2/settings-myproject.xml ~/.m2/settings.xml
else
echo "The config for $1 does not exists. We have either personal (-p), myproject(-m) or xebia (-x)"
fi
echo "=========================="
java -version
javac -version
mvn -v
head -n 1 ~/.m2/settings.xml
A sample output of the script

Automating Predictions

In one of my projects, I had to take up the role of Scrum Master in a team that was already pretty mature in using agile. As a scrum master, all I had to do was make to make sure there were no blockers or upcoming blockers. It was a standard process to identify, if a ticket is taking longer than expected, it might be having troubles. At the end of the day/week/sprint, we had to submit a report on progress.

Since I had way too much free time, and because Jira already provides APIs I created a tool to read our Jira board and analyze the progress. It helped me in understanding the progress, create and email the report in the expected format, to the stakeholders and find out potential problems that might arise due to upcoming leaves in the team, etc. I am not going into details, but this tool helped in predicting sprint status ahead of time so that corrective actions can be taken.

However, one fact is that many times writing code to get something done takes longer than doing the task manually one time. There are a lot of unknowns that we need to figure out before automating. We also need to be aware of the complexities involved. If a task can be done manually, the pressure to deliver something within a specified time sometimes stops us from automating the tasks. So how to decide if a task should be automated or not?

Xebia Essentials: Three strikes and you automate

Xebia believes that it takes 3 strikes to automate. The first time you do something, you just do it manually. You don’t understand the complexities and you don’t know how much effort it is to do manually or automate. Also, you don’t even know if this is a frequent task worthy enough of being qualified for automation. Hence if you are doing a task for the first time, you always do it manually.

The second time you do something similar, you wince at the repetition but you do it manually anyway. You do not automate it for the second time, because it might be a coincidence that a similar task has appeared before you. But this time, when you are doing it, you are making notes. These notes are going to help you when you automate.

The third time you do something similar, you automate it. Repeating something three times manually is a sin.

Xebia Engineering Blog

The Xebia Engineering Blog