This weekend, several of my coworkers and I set out on a mission to hack our company’s culture. If you don’t already know, my company Next Jump has a very unique culture that is tuned around a simple concept. Better Me + Better You = Better Us. Much like Maslow’s Heirarchy of Needs, where you must meet physiological needs before you care about higher level needs like safety, love, esteem, and self-actualization, this concept believes that a stable foundation must be built before you can succeed at the higher tiers of personal growth. The company believes that to reach success, we must start by investing in our people and making them better (Better Me). After doing this, our people will invest in each other and pay forward this debt by helping grow those around them (Better You). When our people are growing personally and helping others, everyone begins to grow and succeed (Better Us). One way Next Jump practices this is through our annual Hackathon. Employees are encouraged to form teams with others that they do not normally work with and then choose a project of their own fruition to challenge themselves to make a product that pushes an edge to the extreme within 41 hours. That is from 8pm Thursday night until 1pm Saturday. This year the winners of the challenge will get two weeks to work on their projects full time to complete their vision.
I decided that I wanted to make something fun that would foster collaboration and creativity across the entire company. Our developers, DBAs, NOC engineers, and business people often find themselves working in silos where they are not communicating well with other stakeholders. This prevents us from solving problems as quickly as we could with fluent communication. There are also many technical and procedural hurdles that make it difficult for anyone who is not an experienced developer to work on code and that make releasing code a time consuming delayed process that often distances a developer from the finished piece of work they are creating. Often, people tend to work on the same areas of our site code and might become too close to the problem they are working on to obtain a fresh perspective of the problem. It would be great if we had a way to extend our Hackathon to a continuously running Next Jump side project that anyone could contribute to at any time as they wanted to practice or just hack at something fun.
I had heard that Github had actually created a cool robot called hubot that lived in the company chat service. This robot allows people to interact with it for both business purposes, as well as general amusement. They can do some really interesting things such as deploy their site, but it also is used for general amusement such as displaying a funny picture of a pug. The coolest thing about this chat bot was that anyone in Github could work on it and extend it with features easily that allowed it to further adapt to the needs and whims of the company. This was not a revenue focused project, but rather just a hack or side project that people could work on for fun or utility. As more and more people at Github started to use it, it became smarter and started doing really useful things such as deploying their site and performing site operations tasks. They now consider Hubot to be an important team member that actually improves their Site Operations Team’s productivity.
An interesting side note by Zach Holman stated that Hubot also solved two other needs by allowing new developers to quickly dive in and start getting acquainted with the code base and data sources while practicing above the waterline. Additionally, many developers working on Hubot determined that working on Hubot code actually helps them to be more efficient by giving them an outlet to break from monotonous cycles of code and occasionally inject some fun into the mix. This has invigorated them to more quickly react and apply new solutions to the problem at hand.
During a Next Jump idea generation session, I mentioned having a NextJump Bot that lived on our instant messaging service and found that a few other engineers were interested as well. Charles McKenzie, Steve Burnell, and Ezra Velazquez, and Stewart Van Cleave jumped on board and together we decided to build the Culture Hacking Robotic Learning Environment or CHRL-E. CHRL-E would be Next Jump’s installation of Github’s famous Hubot. We could connect it to our corporate OpenFire Jabber server and then the company could interact with it over the Spark instant messaging client that we already use. We would then use the Hackathon time to implement all the supporting infrastructure and scripts required to connect CHRL-E to our business data. The goal we decided on was to make it very easy for anyone to hack on CHRL-E and to have a product that lived past hackathon. It had to be ready to survive on its own by Saturday afternoon.
Installing CHRL-E was straightforward. Thanks to the awesome team a Github, Hubot was released to the public as an open source project. We were able to just download and install it on our own server. We followed the installation guide and were able to get CHRL-E online.
% bin/hubot
CHRL-E>Now we just had to connect it to our Jabber server. We installed the XMPP adapter for Hubot. After installing all the required dependencies, we were able to get it connected to our OpenFire server.
Now the CHRL-E was online we started brainstorming all the useful things we could make CHRL-E do. We knew immediately that we wanted to have CHRL-E be able to report how we are trending towards revenue goals for the week. This is an open piece of data within NextJump so it was just up to us to setup a framework for retrieving the data.
With most production projects, the NOC team will have to setup special db credentials with our DBAs and then we have to make sure developers can’t access the credentials so we can maintain separation of duties for compliance purposes and then the release process gets drawn out and it makes things difficult to work with. We wanted to eliminate this overhead from the CHRL-E project or else no one would want to use it. During the planning phase of the project, I made sure to sit with one of the Next Jump’s top developer and a respected leader in the company to understand how we might be able to easily interface with the company data in the easiest possible way so that people could quickly and easily code, deploy, and experience the result of their craft in real time. John Hilliard helped guide us by showing us an existing internal dashboard platform that had all the required data access and was built using PHP and the Zend Framework just like our production platform. If we could leverage this tool as an API gateway for CHRL-E, we could achieve our goals of making this super easy for our developers to work on. This conversation was instrumental to the project’s success. I don’t know how much time we would have spent just trying to get the environment connected and setup otherwise.
Now it was time to code up the first CHRL-E script. Revenue! We added a basic Model, View and Controller to setup a JSON interface to our metrics dashboard system. This would allow us to interact with an API to return all the data CHRL-e would need. CHRL-E runs on node.js and uses scripts of coffeescript to add functionality. There is some really great documentation of how to write these scripts and allow CHRL-E to listen to and respond to events in the chat room. We added a simple regex pattern to our own script to allow CHRL-E to respond to the word “revenue report” with a simple line stating what the current revenue is for the week, the goal for the week and if we are trending towards this goal or not.
And the final product… (Numbers are not real and we changed the regex to revenue between screen caps).
We went on to add lots of other Shockingly Cool functionality.
Return random NxJ lore such as quotes from our founders, random cool things, etc.
Steve used his NOC Operations skills to make sure CHRL-E could be restarted from the chat window and also made sure CHRL-E was monitored via Monit so that if he died from a broken script or other fatal condition, he would come back automatically!
Report on the current status of our weekly fitness competition:
Posting to a chat room whenever a developer commits code. (Ezra — you need moredescriptive comments in your commits. LOL)
Report on the status of our BiggerHearts Initiative.
Report to our office manager when office items are out of stock.
Hubot also has a wonderful open source script repository where the community can contribute fun scripts such as the Chuck-Norris.coffee that returns random Chuck Norris awesomeness such as:
We have built it, now we hope to encourage our coworkers to contribute to the project and establish a fun playground for testing your ideas above the waterline. If it takes off, CHRL-E might even join our Ops team like he has at Github.
If we had more time, we would fully document the deployment and release process so that its super easy for everyone else to get up to speed and start contributing to CHRL-E. We would also like to work on the following actions:
- Incorporate NXJ’s Daily Briefing
- Get Detailed Fitness Stats for your team and even remind others to go to the Gym and high five those who do
- remind people to submit Coronitas and smurfs (our peer recognition awards)
- allow for top 10/ smurfs/coronitas submissions over chat
- report buzz
- find out who is on call
- Integrate with Jenkins for Continuous Integration/Build status
- various alerts/site status/uptime/etc
- and a lot more!
Some of the challenges we faced were actually get through the Node installation and installing dependencies, and establishing a release process. We noticed CHRL-E kept dieing every time we had a syntax error in the coffeescript, and we ultimately implemented a feature to recover automatically. We had a particularly bad period of time where we were trying to get CHRL-E running as a service as opposed to running in a console session on one of our terminals on the server. We struggled with getting this to work but were finally able to overcome the problem once we understood the environment variable’s relationship to our script’s context. At the beginning we were all excited about the challenge, but didn’t really have any direction as to where we wanted to take it. We had to frequently reassess our situation and make sure we were keeping the scope of the project constrained to our time line. We also struggled to verbalize the problems that we were trying to solve, but ultimately were able to document these and write this post.
During the Hackathon, we made sure to have CHRL-E join the hackathon chatroom so that others could interact with him. We were really excited to see many people in the company ask him questions and start interacting with him.
We are now looking forward to the demo round, judging and hearing feedback from our peers.