We recently hosted our first-ever Zengineering Challenge, an intense daylong event that put our immensely talented help desk software engineers to the test. The premise of the challenge was for engineering to come up with a series of one-day projects that could all be accomplished within a day’s work, by a team of three to four engineers.
We did a few iterations on possible projects, starting out with a list of 50 ideas, ranging from writing web server extensions to improving our email templates. This was whittled down to 10 projects, which then got put to vote.
The final count: four teams and four different projects based around our help desk software.
This team was challenged to extract our REST API from our main code base. Our Zendesk API has been around since 2007 and was built on the sensible defaults from back then. We have since changed our perception on how an API should be done, and how to make API changes less intrusive, so we wanted to take our current API and move it into a separately managed project, give it a versioned namespace, while retaining 100% backwards compatibility.
The team did very well on this task. We now have a better foundation for making our next generation APIs, and look forward to begin surfacing that to our API consumers as well. We are now busy building internal projects against our new API structure and are very happy with how things have worked out.
Most know about our native Zendesk mobile clients for the iPad, iPhone, Android, and Blackberry. We also have a miniature version of Zendesk for generic mobile HTML browsers. It’s quite old and has not been maintained a whole lot. So Team Mobile wanted to take one step back and look at reimplementing the mobile web application.
While this team accomplished a lot, nothing that can be surfaced quite yet. The new mobile site has a more robust routing mechanism for navigating between the mobile view and the regular, fully-sized browser view, and it’s built entirely on top of our API. It’s very snappy, but we still have some way to go in terms of design and UI.
The first versions of Zendesk were built on very early versions of Ruby on Rails. We have since grown our code base a lot and have a lot of dependencies. All these add up and make things slightly more cumbersome to work with. Team Speed dealt with speeding up the startup time for our application, i.e. bring down “time rake environment.”
We were able to shave a valuable 6 seconds off the app startup time, bringing the original 14-second wait down to 8. An improvement that every engineer can attest is much greater than it seems. Less of a wait means less time to get distracted from what you’re doing, and it makes test-driven development just a little more bearable. The bigger wins were in delaying model load, refactoring gem load, and inlining some code on the critical path during startup.
We are all about monitoring and reporting, and we have monitors showing us how Zendesk behaves at all times in terms of throughput and response time. We want more though. This team investigated how to expand our monitoring solution by leveraging the capabilities of Geckoboard.
The product is a visual aggregation of our various dashboards, which continuously informs us about vital metrics such as throughput and response time mentioned above, as well as how many tickets are assigned to development, who is responsible for cutting branches this week, and lots of other internal metrics.
These projects will continue to be developed and fine-tuned as we move along, and we plan on having more Zengineering Challenges in the future, perhaps even one where we’ll ask our customers to suggest projects, so stay tuned.