Automation to Drive Development Productivity

The sudden ring of an alarm clock awakens me. It is the dawn of a new day, where I hurry off to get ready for work. How often in our lives do we encounter this? If it wasn’t for the alarm clock, all that was planned for the coming day would have been at stake, wouldn’t it?

Well, this post isn’t about the values of having an alarm clock nor is it something to promote timeliness and due diligence through the usage of alarm clocks. Instead, it is about my opinionated view on the usage of automation, and how disruptive and productive it can be when introduced into all aspects of the software development life cycle.

I guess, we all do agree that automating repetitive and tedious procedures add value for software development projects. Yet, even though we believe in this so obvious concept, how often do we notice that certain parts of our project development process and workflows, have been overlooked in terms of automation?

We often tend to be optimistic, and rely on “simple” written or even verbal instructions, and expect all professionals that we work with to be likely disciplined enough to follow them.

But boy aren’t we wrong!

Written instructions are forgotten or worse, misinterpreted overtime . . .

My experience has always shown that even the simplest of recurrent instructions, we put aside for a team to perform, tend to become overwhelmingly tedious as time passes on.

Let’s take the example of instructions, we write for setting up prerequisites of a development environment.

We do this with the hope that a newcomer would be able to set it up him or herself, so that experienced members would not have to spend time doing so. However, our hopes are often shattered due to misinterpretations of these instructions, which lead to problems that are sometimes found out at a later stage of the project. Problems resulting from such misinterpretations, generally surface later in the software development life cycle and are very time consuming to solve. That’s when we realize that it is always better to write a configuration to automate this task, than to write instructions for a human.

Automation cannot be blamed for not knowing what happens beneath . . .

It is sometimes debated that total automation creates an environment, where on-boarding engineers would lack true understanding of underlying principles. But I do see it in a different way.

Any tool, even a compiler, would hide and abstract out a certain amount of its underlying process. However, an individual could either go with the flow as it is, or can be inquisitive enough to dig deep and understand the overall principles and concepts of what is being automated.

The mere fact of manual intervention, to provide understanding of something automatable doesn’t seem meaningful to me.

Everyone can and should contribute to automation, EVERYONE. It demonstrates true mastery . . .

There is also a belief that automation holds fit, only for certain aspects of the software product life cycle such as QA, Test Automation and Deployment Automation. However, I believe everything that can be automated should be automated. Hence, improving the productivity of the development life cycle through automation and evolving in a smarter way, is part and parcel of everyone contributing to a team.

For example, a development team could identify repetitive and mundane items that consume their time and pitch in to automate such tasks. Code Templating and Generators such as Yeoman are tools that developers can leverage for this purpose. These are excellent for putting best practices into place, while minimizing mistakes of repetitive tasks that involve minor modifications.

When it comes to setting up development environments, Vagrant is a champion. It enables seamless and error free setup and deployment of development environments among the development team.

Good news, there are lots of tools out there. Bad news, we rarely use them!

Workflow automation and productivity tools have evolved mostly in the realm of Web Development during the past years. Tools ranging from Grunt and Gulp to Webpack comes to mind immediately.

These tools, though minor, have been proven to speed up and reduce the recurrent work done by a developer. Tasks like Code Minification for file optimization, hashing files to avoid cache updates, and many more recurring tasks, can be automated through a well thought out workflow for modern web development.

If done manually, a developer would need to perform each of these tasks and the degree of error in missing one would be relatively high. Even when it comes to attaching scripts to a web page, the days where manual script tags being referenced individually is long gone. Web tools are now capable of identifying dependencies and logically sequencing the script files that go into a web page.

Functions such as Continuous Integration (CI) and DevOps also gain immensely from automation. Containerization technologies like Docker, Rocket and LXD provide isolated sandboxed environments to build, deploy and run in a repeatable fashion. Build recipes written through Ansible or Chef, ease out the struggle in maintaining a continuous pipeline and build flow.

Start early, it makes things easier . . .

Therefore, from the very beginning, starting off with the intuitive developer who is driven towards automation, the source control that automatically triggers the build in a CI server and the point it is deployed and finally to an automated test suite, which is executed to verify the build stability, an automation pipeline should be facilitated. This brings focus to minimizing defects and error prone situations throughout the entire software development life cycle. Ultimately this will uplift productivity.

Planning for automation at the start of a project, at its infant stages, yields in easier adaptation. If overlooked at the start, as any change, automation too would become an anchor and a rigorous task due to complexities added later on.

Therefore, automation planned out carefully, considering developer productivity to testability during the early stages, results in automation artifacts that are similar to the other product artifacts. These can be versioned and would evolve with time.

Though the ROI of automation may not be obvious in the short run, automation is a silent servant that proves its worthiness in the long run.

References: DeveloperDotStar