Section 12.6. Automation Discipline

12.6. Automation Discipline

The theme of automation has been mentioned numerous times throughout this book. Perhaps the best thing about automation for most people is that it is impersonal in nature. Imagine yourself as a developer who has committed code that has broken the build and stopped other developers from making progress. You'd want to know about this mistake as soon as possible, but you don't really want other people moaning at you, or your manager hovering over you. A machine-generated email is a pleasant way to become aware of your errors. Your manager and colleagues can expect you to act on the email without having to come and hound you; this in turn builds trust over time.

That said, some form of Pavlovian training may be necessary to reach such a state of trust within the group. Effective forms of carrot and stick are numerous. Free lunch can be provided at the end of a week with no broken builds (or whatever the current problem is). Glowing lava lamps and traffic signals have been used to proclaim the state of the build (http://www.onjava.com/pub/a/onjava/2004/11/10/automation.html). Those who hinder others can make small payments into a group fund, with proceeds to be spent on something for the group. I have an ugly picture of a cat with tearful eyes painted on black velvet that people who break the build have to hang in their cube for a day. A public summary of the state of the group can also do some good, just like the signs you see in factories proclaiming "42 accident-free days."

I find the most useful encouragement is to make sure that the expected process to avoid problems has been documented (e.g., "How Not to Break the Build"), and then to ask precise and detailed questions when there is a problem until everyone understands which part of the process was not followed and why. The process may really need amending, in which case everyone wins. If not, the business of being quizzed may dissuade future offenders.