Saturday, July 7, 2012

Keep It Simple, Stupid


I had a great time last week at DevOps Days in Sunnyvale. The presentations were great, I attended some thoughtful break out sessions, and I learned about some pretty cool new tools. Much of this is being covered by the rest of the folks there, so I won’t reiterate it here, but what I did want to discuss is the underlying theme to much of the successful tools, methods, and ideas that were presented: keeping it simple.

We’ve all heard it before: keep it simple, stupid. However, almost every time I hear it, we’re talking only about software or process. Yes, that makes sense. We can observe many of the most successful tools and processes in our industry achieved that description because they were simple. What struck me extends beyond just the software and the tools. Keeping it simple succeeded on a grander scale because of human nature, and that human nature applies to so much more than just software and process.

 Many, if not all, of us involved in DevOps or pragmatism have a certain mindset. We are passionate, outgoing (albeit if only technically), and curious. We are a minority. The success of a new process or tool within our group does not promise success anywhere else. The majority may not have the drive, the passion, or they just lack the time. To achieve success with that majority, the new system must cater to those characteristics.

Consider the technical reader’s preferred source of knowledge. Only a small percentage of people I see nowadays still read entire technical books. However, innumerable people seem to be reading blogs, feeds, hacker news, etc. Why is that? It’s probably because a blog isn’t complicated. A blog is short, to the point, and often summarizes a longer (harder to read) technical piece.

In the non-technical world, consider cooking. Much the same, few people I know nowadays cook elaborate (read prep time > 25 minutes) meals for themselves. The norm seems to be defrost-able, quick prep time, or eating out. And how many young couples buy cookbooks and use them versus just searching the web for simple recipes?

My proposition is that the adoption of new process, tools, or approaches to thinking is driven by a minority and succeeds when those new processes, tools, or ways of thinking are presented to the majority in a simple, digestible fashion.

If we want to spread the adoption of DevOps (cultural changes, new tools, and states of mind) throughout our industry, then we must commit ourselves keeping things simple. I fear that heavy featured tools with long technical manuals, lengthy technical books, or new groupthink will not be readily adopted or consumed. Rather, their wondrous benefits and knowledge will stay locked in their manuals, between their covers, or in our minds alone, their collective surfaces barely scraped by some curious, but time-strapped or non-motivated, souls.

2 comments:

  1. Have you seen Rich Hickey's (creator of Clojure) talk, "Simple Made Easy"? http://www.infoq.com/presentations/Simple-Made-Easy

    "Rich Hickey emphasizes simplicity’s virtues over easiness’, showing that while many choose easiness they may end up with complexity, and the better way is to choose easiness along the simplicity path."

    One reaction I have to your proposition is that it's really only when there's a new generation of people do new practices actually take hold at a large scale. Doing things as they were when you first learn them has a crushing hold on everyone. People who change are rare.

    ReplyDelete
  2. I have seen it -- thanks to your suggestion ;-)

    You have a good point about when change happens; and your other statement about the crushing hold describes the "majority" as I termed it in the blog -- I totally agree.

    I figure that the article can be interpreted various ways, but my overall takeaway is not that we *need* to change anyone, but if you're planning on trying, keep it simple =)

    ReplyDelete