It all started while I was on on-call. I was relaxing at home, and, as luck would have it, the phone rang. A customer was having trouble using one of our applications. We quickly assembled a team of experts – the application manager, a business analyst, a system owner, and some other technicians – only to discover that the customer couldn’t reach our services from within its network. A few days later, a similar issue came up with a different customer. And again. And again.
It became somewhat common, particularly for travel agents working from home and having difficulty with their Internet connection or travel agencies that have Internet access policies that block URLs needed to access Sabre Red Workspace.
By reviewing just one pattern in the logs, we realized what had happened. This made us wonder … how about a tool that could look for those patterns automatically? It could save our time, budget, nerves, and solve incidents faster. A tool like that could be used by most teams. And that’s how our idea was born.
Instead of making a business case to see if we could use a special fund dedicated to testing out employee innovations, we decided to create a prototype in an upcoming HackDay at Sabre’s development center in Poland. These 24-hour events happen two or three times per year, and give employees an entire day to focus on developing a “hack” of their choosing.
We immediately started planning — how the tool should look and what technology to put inside. We came up with hundreds of ideas. But, with only 24 hours to actually build it, we made a map of ideas and divided them into milestones. We determined what should go into the basic application, and then came up with another list of features to add if we had time.
Finally, HackDay arrived! We fortified on Snickers and Red Bulls and started working. The tool took its first “breath” after two hours of development. That inspired us to keep coding until late in the evening. We had a fancy graphical user interface (GUI), a simple but efficient core, a basic data set of patterns and marketing keywords. Once we had a working application, we continued to add new features in micro-iterations of about an hour each. Luckily, there was pizza to sustain our creative juices and stoke our motivation!
While it was definitely a long, exhausting 24 hours, it was worth it. We were all excited about what we achieved – we had brought our idea to life! Of course, it was also a good reminder about how cool it is to work for a company that gives its employees time to “play” and test out innovative ideas.
The next day (after we’d all gotten a little sleep), we were looking forward to the HackDay closing event. This is when each team talks about its hack. Our hack provides a way of detecting chains of patterns in computer log files our customers send us when reporting a problem. For example, we search for a “Message send failed” message in the log for above described problem. After our team wrapped up our demo, we got a huge round of applause. And then, the best part of the story … we won.
But the story doesn’t end there. Our Hack Day creation lives today and is used with some of the incidents our customers experience with Internet access. We hope to one day build it out by adding new rules to the database so it can be used more broadly across the company to help solve customer issues more quickly.
Our vision is that over time and with additional development, this tool could one day fill a significant gap for our Help Desk – and could be used by business analysts to filter out incidents that the first level of customer support are unable to resolve, but which don’t need developer’s expertise. Customers would get faster resolution to an array of issues while productivity for developers would rise.
Here’s to many more tales of Hack Days with similar happy endings!