According to Jeff Atwood of codinghorror.com, the three key rules to quality software development are KISS, DRY, and YAGNI. These rules don’t just apply to development best practices, they apply to quality DevOps best practices as well.
KISS – Keep It Simple, Stupid
“Needless complexity gets in the way of actual work.” (from: http://c2.com/cgi/wiki?KeepItSimple)
Minimizing operational complexity is the hallmark of a good operational engineer (and a good developer!). Favor simplicity and consistency over complexity and automation. Complexity breeds confusion and lots of poorly maintained documentation.
Prevent and avoid “gold plating”: the creation of functionality that isn’t required and that adds unnecessary complexity (see YAGNI below). You should focus on solving the immediate business problem, which might not require any coding or automation at all.
If you do end up needing to craft a bit of code, like a script or an application, to solve your problem, create software that you would enjoy using. If that little script you wrote has more than three command line arguments, and/or you find yourself looking at the source, the help message, or some manual you created for it, odds are it’s too complicated.
Don’t worry about “what if” or “gee-whiz” features. For example, pretty much any animations you put in a line-of-business application – except for things like progress bars and “loading” images – are a waste of your time and your organization’s time. Again, focus on the simplest solution to the business problem at hand and you will be successful: keep it simple!
DRY – Don’t Repeat Yourself
“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.” (from: http://c2.com/cgi/wiki?DontRepeatYourself
If you are copying and pasting config values or files all over the place, You’re Doing It Wrong. Duplication causes operational risk to go through the roof, and a tremendous burden is placed on the system operator to not make mistakes.
When configuration values exist in multiple places, those values can very quickly and very easily fall out of sync with each other. Here’s an example: say your Database Administrator says she needs to migrate your primary production database to a new server. Not only does it require new hardware, but it requires a new hostname for the server as well.
Typically, applications have a database connection string in some sort of configuration store that tells the application how to connect to its database. If that configuration store is an XML file that lives in the application’s installation folder on the local machine, how do you update it? Just edit the file, right? What if that file is copied across 200+ desktops? How can you be certain you updated every single config file out there in the wild? What started as a simple file edit can quickly spiral into a system administrator’s nightmare.
Whenever possible favor things like templates. Strive for a Single Source of Truth, like a central configuration repository where configuration is specified once and only once.
YAGNI – You Aren’t Gonna Need It
“Always implement things when you actually need them, never when you just foresee that you need them.” (from http://c2.com/xp/YouArentGonnaNeedIt.html)
Wouldn’t it be awesome to have a database with an inventory of all software applications deployed by your DevOps team into production including deployment dates, rollback instructions, target machines, etc.?
But take a step back. Would it really be great to have a system like that? What actual real business value would something like that deliver to your organization? What effect would it actually have on your organization’s bottom line? And what about the costs of building such a system or maintaining the code that went into creating it, not to mention maintaining the data it contains?
Keep your organization’s actual mission and goals in your mind when deciding on whether or not to start any project or a new custom-built software tool.
