Don't Repeat Yourself

One of my favorite books as a system administrator is Andy Hunt and Dave Thomas’ “The Pragmatic Programmer.” It is a book built around 70 tips, ostensibly for programmers, but I find that most of them apply just as well to system administration.

My favorite tip, by far, is “DRY – Don’t Repeat Yourself.”

In an interview Dave Thomas explained DRY: “DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system’s knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.”

Every day I fight repetition and duplication. Some days it’s a developer wanting to put things in /etc/hosts. Other days support staff want to take a copy of my documents and put them in their own knowledge base. Or they want to take my machine build process and make a copy for themselves. Or, in our configuration management database (CMDB), they want to note server specs in application records.

“So what?” you say. “A copy doesn’t hurt anybody, and sometimes helps.” I disagree! Remember that only the authoritative source for the information will be up to date. So when DNS changes, /etc/hosts won’t. When I update the OS information for a server in my CMDB the application information won’t get updated automatically. Things get out of date, and it becomes difficult to get them back in sync. Teams waste time and money dealing with the problem. People get confused, and sometimes the confusion results in poor responses to problems, bad feelings, and more wasted time. In some cases systems are damaged, because people use old procedures.

So how do you get around this? Frankly, just don’t repeat yourself. Instead of making a copy find a way to share the authoritative source. Choose to put things in DNS rather than /etc/hosts, and use ACLs if you want to keep it private. Be careful where you put data in your CMDB, for an application doesn’t need OS information, and vice versa. Ask yourself, “is this information kept somewhere else?” and if it is, don’t make another copy. Or, if you absolutely have to make a copy, make sure it synchronizes automatically with the master. I always try to avoid that, though, because the system to make the copy requires maintenance & monitoring, too.

Duplicating data is a shortcut which saves a little time now but ultimately costs a lot more if it isn’t thought through properly. Avoid all those problems: just don’t repeat yourself to begin with. 🙂