Integrate Button: Continuous Integration, Deployment, Testing, Feedback

Does Automation make us less communicative?

We spend a lot of time automating software delivery processes. For someone who spends a lot of time removing humans from repetitive, mundane and error-prone processes, I spend a lot of time talking with people. In particular, my time is spent in helping others understand that automation will make their jobs easier and that software/systems professionals should be focusing on novel activities, not doing the same thing over and over again and calling it work. However, inevitably, I've heard a similar question numerous times:

When you automate so many processes, do people spend less time communicating with each other?

The obvious implication is that automation leads to less communication. I cannot disagree more with this. In fact, I've found it leads to much more effective communication. Prior to designing and implementing software delivery automation systems for our customers, we typically find that organizations have instituted "walls" between teams (such as between development, QA and Systems/Operations) and no one is communicating with each other. They might be "talking", but they are not effectively communicating. Most of their conversations center around things like "but, I thought you were supposed to do that?" or "I forgot to copy the file to that location" or "will you provide me the authentication information for XYZ host?" If this is the kind of communication people envision in their theoretical "non-automated world", I'd rather talk about the latest dumb show on TV.

The reason we find that organizations communicate better after we automate their software delivery processes is because the automation becomes part of the overall software delivery system. For instance, when the developer checks a build/deployment script change into the version-control repository, it is used by QA and the Systems/Operations teams and vice-versa. No longer can team members get away with the "throw-it-over-the-wall" approach and abdicate their responsibility. Moreover, because it's all tied into CI and build management servers, they get instant notification when something does go wrong so that the fix is usually minor and made quickly. As I often like to say "Automation is for the People".

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.

Fire your best people...reward the lazy ones

Fire your “best” people…reward the “lazy” ones

In my experience, what most people consider to be their “best” people are often the root of most problems. It’s the difference between troubleshooters and troublepreventers.

Let me explain…

Bill is a troubleshooter (only). Many consider Bill to be the best employee in the company because he solves almost any problem that comes into the door. However, unbeknownst to many (especially management), Bill is the one causing most of the problems. Bill knows the purpose of every hard-coded lookup value and is the fastest to manually deploy the application to WebLogic using its web console. For instance, he knows that “14″ means a “transaction that is waiting for approval by second-line management”. However, instead of creating a human-readable constant, Bill hard codes the number “14″ in the source code. Therefore, Bill is the only one that can easily maintain these methods. In my personal experience, someone like Bill doesn’t do this for nefarious reasons, he’s just not thinking about how the next developer may need to maintain it. For every time a method is written, it’s read (and maintained) ten times (10:1). Therefore, people like Bill need to be writing source code for other humans, not the computer.

Let’s have a look at Peter…

Peter is a “lazy” developer (a troublepreventer). Because Peter is “lazy”, he hates doing the same thing twice, so he generalizes common functionality into a delegating class, creates interfaces for implementing classes to adhere to, or he writes build scripts that compile, integrate the database, runs tests and inspections, and deploys the software the same way every time. Peter finds it mind-numbing to repeat himself. Again, Peter is lazy so he doesn’t mind spending two hours automating something that normally takes 10 minutes to run manually. Why? Because, he very quickly reaps the benefits of this extra effort since every time the process is run he gets those 10 minutes back and even more importantly, he eliminates the possibility of human error (which, again, saves time and money).

The (”lazy”) troublepreventer thinks ahead. He extracts variable information into common properties files, seeks to reduce complex code, and automates repetitive, error-prone activities such as the build and deployment processes. He also ensures that others can very easily repeat what he has done. Anyone that has worked with me for even a day knows that I often sound like a broken record when I say “Is it in Subversion?” or “Have you updated the Wiki?” To me, if the knowledge is locked in your head, you are a less valuable, not more valuable, resource. Troublepreventers put their knowledge in the system, not just their heads, so that it runs the same way every time.

People like troubleshooters because they can solve a problem when a project is under pressure such as getting that emergency fix out the door immediately. Without question, you need troubleshooters on your project. However, many times the (exclusive) troubleshooters are the ones that cause the problem in the first place, be it a hard-coded value, duplication of code or a large complex method only they can understand.

Before you start thinking that I’m trying to gather together a group of slackers, I’m suggesting the complete opposite of this. I just want people to think about the total time involved, not just fixing the symptom. There are people that are both troublepreventers and troubleshooters. These are the people you want to keep and reward. However, on a given team, I’d opt for more troublepreventers than troubleshooters as they save everyone time, money and headaches.

Originally posted on testearly.com