Uncharted Waters

Feb 1 2016   8:43AM GMT

The Real Effects of Automation in Software

Justin Rohrman Justin Rohrman Profile: Justin Rohrman

Test Automation

Automation is here for good in software development, and it will have big affects on how we work. But not in the way you might think.

In 1779 a man names Ned Ludd got tired with mechanization and industrialization reducing the number of jobs available for skilled craftspeople. Ned led a group of people in what he called ‘machine breaking’, sabotaging the machines in hopes that it would stall progress from industrialization. They broke a few machines, but couldn’t keep up with the pace that they were being made. These people eventually became known as the Luddites.

Automation and using machines isn’t going anywhere for the software industry either. If anything, it is on a rapid upswing right now. Let’s take a look at the unintended side effects of this trend.

Ten years ago automation in software was a dream. It was something every manager wanted but the technology wasn’t quite there to make it useful. Sure, we had unit tests, that had been around for a while. But, for most people that was a bit like flossing your teeth. Something you only did right before you knew someone was going to ask you how often you write tests for your code.

Things are different now. New frameworks and tools come out weekly, and they are getting pretty good. Good enough that developers and testers use them and can make them work for large projects. So now, we have this onslaught of tooling that  while isn’t exactly testing, can help people design better code and make changes without panic attacks from wondering what else you broke.

As a result, we see the job market shrinking and average skill level declining.


I was in the Boy Scouts as a kid. Our troop leader was a history professor at a local college and specialized in Texas history. For one of our merit badges, he took a few of us boys out to the San Jacinto Monument with a compass and a map to walk crucial locations in the Battle of San Jacinto. After a few hours we had plotted where the different armies were and where the battle actually took place. There was no Google Maps, and no commercial GPS back then. If we went driving somewhere new, we used Key maps. If there was road work, or some unexpected detour, well you just deal with it and find a new way to go.

I’d guess there aren’t too many people that can navigate with a compass and a topography map any more, me included. I can only tell north from south by landmarks in cities I am already familiar with.  In straight forward  situations — a left, go up a couple blocks, turn right at the giant oak tree — I can still do alright. But when a challenge comes up, things get sketchy. Relying on automated systems like GPS stole my ability to deal with anything out of the ordinary in travel.

Automation in software is on an upswing now. A few companies are trying out continuous delivery, but for the most part it is on the horizon. The aim in continuous delivery is to completely remove judgement from the release cycle. Write come code, check it in, and if the automation is green then everything goes to prod.

Sounds pretty nice, right? It is, except when something goes wrong. Just last week, Github had an outage that made most of their many users unable to use the service. Would a person have been able to discover this problem on an internal environment before it happened in production? It’s hard to say. But, we know what happened when people were cut from the equation.

There aren’t any Ned Ludd’s out there going around software companies misconfiguring CI systems or and stopping automated deployments. Service outages like Github are a good reminder that tooling can’t replace people, especially when we are working off the plan.

3  Comments on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.
  • molneck
    I had no idea that computers had progressed to the point of feeling emotions.
    20 pointsBadges:
  • SHiggins
    The positives of automation will always outweigh the negatives. Automation delivers within the boundaries that it is designed to operate in whereas humans are capable of error in all circumstances. We already "trust" ourselves to automation when we fly, is doing the same in testing a scarier proposition? Driver less cars are just around the corner and we WILL all have one. Not through choice or convenience but because the insurance companies will look at the statistics, see the true cost of human intervention, and charge accordingly. :0)  
    10 pointsBadges:
  • TheRealRaven
    Automation regularly has negatives that outweigh the positives. Every failed automation project provides evidence. Almost all automation projects are initiated and implemented by error-prone humans.

    Until the entire process can be done in a method that eliminates all possible errors and points of failure, only some or possibly most automation projects will have net positive results.

    Numerous examples of net-positive automation are indeed available all around us. But essentially all of the successful ones are simply final results of much trial and error. (Attempts that never succeeded take a little looking, but many more can be found.) Even cloning successful examples can be shown to have risks. It doesn't always work.
    36,955 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: