There's a big difference between automated and automatic

In our work, we interact with people from many different teams: developers, QA/testers, operations, etc.. In some organizations, operations may be further segmented into SCM, DBAs, Security, and so on. And, in other cases, some functions might be combined. But, if I had a nickel for every time I asked someone whether some process was automated and they incorrectly told me yes, well...you know the rest. This is why definitions matter sometimes. It's the difference between automated and automatic.

What they mean is:

• We wrote some scripts for that
• You have to log into each of the machines separately to run the processes
• Your environment/machine has to be configured just right to run the scripts
• You must manually execute each of the scripts separately
• A human must be present to run the scripts
• It's "automated"
  

What I mean is:

• The scripts are run headless (i.e. from a single command)
• The scripts are checked into the version-control repository
• The scripts have been integrated into the build and/or deployment scripts -- and all processes can be run from a single command
• That the automation is automatic

The difference between the approach they think is automated and what I think is automated is vast. But, it's not about using the right definitions; it's about having a common understanding of the goals you want to attain. The "manually automated" approach leads to significant bottlenecks (real scenario: 100 projects and 10 target environments per project means that your development is stopped every single time someone must manually perform these repetitive activities).

So, the next time someone tells you "(their) stuff is automated", you might want to ask a few questions because each manual task slows down the entire process which costs time, money and frustration.

Comments

[Peter Kofler]

Thank you for making the distinction clear. The big difference is not only in common automation, but also in coding related topics like testing or code reviews. For me automation is a base principle to ensure code quality. It's necessary to fight our own sloppiness.

[Levent Gurses]

Paul is an authority on CI and build automation. As someone who had the privilege to work with him on multiple large-scale automation projects I could not agree more with the thesis of this blog entry. Especially the part where "...a human must be present to execute the stuff...". Many times managers think they have true automation, while in reality they only have person-dependent semi-automation. Clearly an important distinction for teams who want to maximize their investment in build and deployment automation.