Section 3.3. Why Automation Is Vital

3.3. Why Automation Is Vital

There is no separate chapter on automation in this book, because I believe that automation is vital in all aspects of a development environment. If you do something nontrivial twice, then at least document the steps that you followed. If you have to do it again, consider automating it. If a task has two or more steps and is manual, then someday someone will either perform the two steps out of order or forget one of them.

Three Strikes And You Automate

• The first time you do something, you just do it manually.

• The second time you do something similar, you wince at the repetition, but you do it anyway.

• The third time you do something similar, you automate.

(Martin Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999)

Automation by reducing the repeated parts of a task to a single command is one good idea. Improving tools and other parts of your environment will relieve the short-term points of pain, but automation will raise the whole level of productivity of your project one notch.

While it is easiest to automate an environment when it is first created, automation can be gradually introduced to an existing environment. First choose an automation environment (see the next section, Section 3.4) and then begin by automating how source code is obtained from your SCM tool. Then automate running a build using that source code. Then work out how to run unit tests and capture their results automatically. Finally, make sure you can automatically update bugs with details of the build, create change logs and a list of bugs fixed in each build, tag the source files, and deploy the results of the build and tests to a suitable location for the rest of the project members to use. Once all of these steps have been automated, you won't have to do any of this manually. Each of these steps is discussed in the relevant chapters. The point is that you can add automation one piece at a time.

However, automation does have some consequences:

• Debugging a process once it has been automated is somewhat harder than debugging the manual version of the same process. This is because there are usually more logfiles, configurations, and other levels of indirection to understand.

• If a task doesn't clean up all of its temporary files, logfiles, and other output, then some disk or other will eventually fill up. If you can't change the task to clean up after itself, then establish a policy about how many days' output should be kept, do some calculations to see whether the available disk space matches the policy, and then make sure that the older files are removed, preferably by another automated task.

• Even if storage space is not an issue, programs should always clean up after themselves, if only to save people from having to ask what a file is for and where it came from. Leftover files tend to be created faster by automated tasks because they are easier to run without thinking about side effects than are manual tasks.

• Other resources such as CPU cycles, network bandwidth, and other server loads should be monitored to make sure that the automated task is not stopping other people from working. If you know what your task is doing to others, then you can fine-tune when it runs. If you don't know, then automated tasks are easy targets for blame if everything starts to run too slowly.

• How do you know when an automated task is broken? Sometimes, as with builds, this is obvious: there's no new build. Other tasks' effects are more subtle. For example, cleaning up old builds and their entries in a bug tracking system will require more than just checking that there is now more free disk space available. There are numerous monitoring applications available, mostly customizable, that work well if you put the effort into defining their tests. Mailing the daily state of an automated task to yourself (or even better, to an appropriate email alias) as a "heartbeat" will give you examples of what a task is supposed to do, which is very useful when something changes unexpectedly later on.

• There is the dismay when something breaks in an automated task and you have to reconstruct how the task was supposed to work when it was run manually. This is where the documentation of the manual task becomes very useful, even more so if it has been kept up-to-date.

The places where tasks are automated are also good places to document the details of the task. Whether done simply as comments in a shell script or a build file, or set up to provide helpful hints during an installation process, the documentation will remind you later why something was automated in a particular way.

Automated long-term monitoring of an environment is also an excellent way to gather statistical information that can be used to plan for investment in a development environment. For instance, hard data showing how the performance of a particular server has changed over a year is the first step in deciding when to upgrade it, or to answer vague comments from developers about how "everything seems slower recently."

Automation is one mark of people who are thinking about what they are doing as they write software. If you find yourself working in an environment where there are many manual steps, first document them and then automate them for your own use. Once they work well for you, generalize them for others in the project. If you can get someone else such as the project's toolsmith to take over the automation, so much the better.

Finally, the following definition made me smile and nod in agreement:

Oughttamatic: (adj) Programmable in principle, but considered so trivial in practice as to be often performed manuallythus guaranteeing occasional errors. Ex: "Yeah, it's the third time I've created a new passwd entry using cut-and-paste and forgotten to increment the UID; I really oughttamate this." (Karl Fogel, http://www.red-bean.com/kfogel/glossiary.html)