About a year and half ago I published a blog post about ChatOps at VividCortex (if you’re unfamiliar with ChatOps, that original post still serves as a good primer). At the time, we were smitten with the new technology -- I wrote, “We are huge believers of ChatOps at VividCortex… GitHub’s implementation of ChatOps is amazing and has inspired me to spearhead ChatOpts within our office… ChatOps has really revolutionized how we operate.” In the months since, I've learned a lot about implementing ChatOps so that it functions as more than just an office toy.
It’s taken some time, reflection, and experience with ChatOps to really begin to understand how chatbot technology grows within a company culture. In some ways, VividCortex’s adoption of ChatOps has been a resounding success. But in other ways, it hasn't taken root quite as I was hoping. That said, there are still fantastic reasons to be a ChatOps believer, and to understand how to best apply it to your company and team. So, if you have a chatbot that doesn’t seem to be earning it's keep, here’s some insight on why ChatOps might not be optimized at your company, and some advice that should help get the lazy robot back to work.
1. All Fun And No Work
Chatbots are great company morale boosters. Chatbots encourage co-workers to hangout in the chatroom, at any time. And they’re good, fun teaching tool: if some employees are new to ChatOps, watching their co-workers in the chat can get them used to running chatbot commands themselves. And a lot of these commands are fun. The silly commands and reactions that you can program into the bot absolutely have a place and time. However, at some point your chatbot needs to prove it's a productive member of your team, beyond just summoning up random pictures of cute cats or insane emoji bombs.
In my original post, I suggested that “all work and no play makes Hubot a dull robot.” And I stand by that. But try separating work and play. Once you’ve had your chatbot for a while, seeing the funny commands in the chatroom while you're trying to have a serious discussion will turn annoying fast. At that point, it's time to create a separate, dedicated room for the fun stuff -- we simply call ours "The Fun Room." And that’s where everyone can go to get their fill of doge memes and hold my beers. At the same time, a little fun is ok (great!) when appropriate. Nothing makes a failed deployment better than a cute picture of a kitten. So, don't strictly enforce “No Fun” outside the fun room, but having a fun room certainly helps.
2. Help Command Is No Help
Almost guaranteed: once you get a chatbot, the first thing that’ll happen is someone will install every chatbot script on the internet. As a result you’ll quickly find that whenever you want to find a command ask your chatbot for help, it’ll spit back pages upon pages of useless commands. A good chatbot will include a search feature, but if you don't know what the command is called, even the search function won’t be very helpful.
So, tagging FTW. If the number of scripts is getting to be so high that your help command isn't helpful, you should think about categorizing your commands. VividCortex uses a Hubot that doesn't come with a default way to put commands into categories, but other chatbots might.
The easiest way to categorize is to add tags to the command help for each script. For example, try adding “#ops” to all the commands that are useful for operations-type functionality and “#fun” for the fun commands. Now you can run “hubot help #fun” and, voila, you’ll only get the fun stuff. To add further context to what those groups mean, we created a tags.json file, which is just a map with the names of each tag, plus descriptions. Now we can even run “hubot tags,” which will give us a list of all known tags.
3. Help Inception
If your script does include a huge number of commands, try jettisoning standard help comments, such as those that Hubot offers. Not only can these comments junk up the “hubot help” command, they also limit you to a single line description. Instead, sub-help, try adding a response to “hubot my-command help.” In the standard help comment section, you can just have a single documented “hubot help my-command,” which will then be available to offer deeper details when necessary. You’ll be free to add as much detail as you wish about the command without fear of cluttering up the main help.
4. Syntax Suckage
There isn't really a defined syntax for your chatbot commands. The community has provided scripts that have a tendency to formulate commands in such a way that the mirror conversation, with a person, like “chatbot gif me pugs.” For fun commands, this is fine. However, for tasks that are meant for business, it would benefit you greatly if you standardize a common syntax. If not, you might find employees spending an inordinate amount of time checking help commands to figure out syntax. This puts even more strain on a company’s adoption of ChatOps, especially at the beginning. My suggestion for a standard syntax is “bot module action key=value…”. So, for example: “hubot deploy api-metrics to=prod tag=current config=true”. However, it really doesn't matter as long as it's consistent.
5. If Nobody is Doing, Nobody is Learning
One of the best value propositions of ChatOps is "Employees learn commands by seeing others execute them." But what if nobody is using the commands? If you don't have your co-workers regularly choosing to use ChatOps you lose this potentially awesome learn loop. And this learn loop is important to gaining ChatOps adoption. If they aren't executing the commands in chat, where are they? Make sure that your team is really on-board and understanding of the value of the public commands involves in ChatOps -- often times just communicating the value is enough to get people involved and start building good habits.
6. Getting The Bash Ninjas to Reveal Their Secrets
Bash Ninjas live and breathe the terminal. This is where they feel the most comfortable and productive. Asking them -- or, even worse, forcing them -- out of the terminal will likely be perceived as a gesture of disrespect. The problem with the terminal is that it's hidden from all eyes but the Ninjas’ own. This goes against ChatOps principals. How can we get the ninjas to use chat? The short answer is you can’t expect them to use it all the time. However, if the commands they use in the CLI also work in the chatroom, every now and then, when it's convenient, they might be persuaded to choose chat to practice their BashFu.
7. Sharing Isn't Caring
Maybe you find yourself contributing commands, but you’re the only one. Why isn't anyone else? Well, the truth is that sharing isn't about caring after all. We share because there is some form of benefit for ourselves. For instance, making a donation to a nonprofit is great for the nonprofit -- they can use those goods or money to help others in need -- but no matter your altruism, there’s still the question: what’s in it for me? You get the satisfaction of feeling like you’re helping to make the world a better place.
The situation with ChatOps is similar. To be honest, you contribute because you think the commands, accessible in the chatroom, make life easier -- not just for your colleagues but for yourself too.
And here’s the rub: there’s a good chance that your clan of Bash Ninjas won’t think that accessing commands via the chatroom will make things better for them. Perhaps it’ll be valuable now and then, but overall it's probably not enough to entice them to share all the time.
8. A Culture Of Scripting
I think it's important to remember that at the origin of ChatOps was the goal to make a directory of shell scripts accessible within a chatroom. So, with this in mind, I think it’s best to encourage a culture of sharing scripts -- not writing chatbot commands. Assuming your Bash Ninjas have the dependencies installed, a script can run on the terminal where the ninjas feel most at home. No matter what language the script is written in, with the help of your choice of chatbot, it's simple to expose it as a command. Of course, if your engineering team is focused on Ruby or Python, it’s helpful to choose a chatbot also written in that language. Thus the barrier to sharing will be lowered even further.
What's really important is to get your team in the habit of sharing scripts. I see this as functional documentation. For instance, you can write a wiki or Google doc about how to do a given task. But that said, there’s still a number of problems with written documentation:
- It isn't regularly validated. Someone might write something and then nobody will validate that it’s correct. Or it might not be recognized as incorrect until a serious problem appears.
- It's up for human interpretation. If the documentation is not explicit in what it's aiming to achieve, interpretation becomes a major aspect of how it’s utilized. Even then, what if somebody misreads that documentation or fails to follow the exact order of instructions?
One of my favorite DevOps terms is "Codification of Knowledge". For the same reason VividCortex has decided that tools like Puppet and Chef are good for documenting managing configurations of servers, we’ve determined ways to document and manage necessary tasks within ChatOps. Not everything can be completely automated, of course; but those task we can simplify, let’s turn them into a command with one or two arguments.
Like any powerful tool, ChatOps still requires some skill and preparation for effective application. Is it worthwhile to take the steps to make ChatOps really flourish in your company culture? We say definitely. And we promise, it’s not just for the sake of increasing the efficiency of your Doge Meme distribution.
Further Reading
Here are a few additional resources to help you improve ChatOps culture at your organization:
- A recent article by Dmitri Zimine talks about common pitfalls with implementing ChatOps. Some of which I also covered.
- James Fryman of StackStorm talks about the reasoning behind ChatOps and also some good advice on structuring your ChatOps syntax.
- ChatOps for Dummies by VictorOps an easy read to help assert the value of ChatOps.
- Some good advice from Libratro as ChatOps moves from fun to a critical tool in your organization.
- /r/chatops for the latest and greatest news and articles.
