Hackathons at Rightmove are a special time for us. It’s a time when people from all walks of life across the business come together to make weird and wonderful things. From that idea that you think is going to be the next big thing for the business to the experiment that gives you the excuse to try out the latest technology people are always buzzing about; the most interesting part of a hackathon are the ideas.
We learned a long time ago that doing hackathons has to be an inclusive event. Just because you aren’t a coder in your daily work life doesn’t mean you can’t take part. We have not only front and back end developers take part but also QAs, team leads, business analysts and members of the business from outside our development teams. In fact, this year one of the most interesting ideas came from a group of customer service wanting to explore modern techniques of reaching out and communicating better with our customers via tools like Amazon Lex.
We set out three days for those taking part, two and half day’s development followed by an afternoon of presenting your results or findings to the entire product development department. Then it’s up to your peers to vote for a winner! This year we had the biggest one ever with 18 separate teams made up of an impressive total of 75 people from across Rightmove.
The first day is usually the crucial bit. It’s the part where your ragtag team need to pull together to divvy out the work so everyone is doing something important and everyone is taking part. Those inexperienced with running or taking part in a Hackathon can often make the fatal mistake here of not preparing a plan.
We’ve learned from the mistakes of our early years of running hackathons and we know preparation is key! These days we make sure that every team is given face time with one of our experienced application architects, not only so that they can bounce their ideas off someone who can give a different perspective on design techniques, but also to go through all the steps they can take up front to be ready to get going before they started in the days of the hackathon proper. These sessions are encouraged to happen a couple weeks before the main event to give time for teams to setup application builds, gather important research knowledge and generally make sure all the tools they need a ready to go.
So hopefully with each team ready now to get going the day rolls around, we all pick up our goodie bags of treats to keep us going. This included the yearly Hackathon t-shirt, who’s design is a closely guarded secret up until the day but never fails to amaze, taking its pride of place in many of our regular wardrobes. We all have our first day breakfast together then it’s off to get started with the build.
It’s important that as a team everyone has a task to do and not just busy work. In the old days we would sometimes have the idea generators come up with something that they know they want to do and how they are personally going to do it, end up with a team of six other developers and then have no idea what to do with all of them, all the while leaving some poor soul on another team devoid of help. These days we encourage a healthy team size of up to four developers in one team. This has the advantage of making it easier to assign everyone a good chunk of the work to do as well as make it fairer when voting time comes around.
Hopefully your team is successful getting the minimal prototype of their idea working by the end of the first day (or have admitted that the scope might need a little tweaking at the very least), so that when day two rolls around you are ready to add some of the bells whistles and polish that will wow the voters.
Over time we’ve learned that going for a peer vote is the best way to encourage a fair result. We’ve dabbled with judge panels in the past but with more people comes more opinions and so that three-man team that looked into natural language processing can catch the imaginations of some of the more technical minded members whilst a Nerf turret powered by facial recognition can amuse the more whimsical.
We try to keep the focus on the doing rather than the winning, as at the end of the day having a chance to try out ideas and learn something new. Our hackathons are first and foremost a forum for people to learn and develop themselves. We aren’t looking to exploit the hard work of others for purely business reasons, though many of our most successful hackathon idea have become features for users on the site like Draw-A-Search and Where Can I Live? Hackathons give people the confidence to realise what’s possible and in some cases to give people the chance to try roles they never done before as business analysts try their hand at front end development in some cases and QAs get to grips with frameworks like Node JS for the first time.
This year our winners were two teams, Natural Language Search input for best idea and a Web App for Giving Praise for best presentation. Both teams managed to beat out all others in what was a close race to win the coveted trophies and vouchers.
Hackathons are great way of bringing people together, to work with those they perhaps never worked with before, to try the things they’ve been dying to try or just to improve their skills and knowledge with tools and tech that they wouldn’t normally get to play with otherwise. They help make our community stronger and reinforce that you don’t need to be a member of the high up management teams to come up with that killer idea and capture the imagination of others to inspire them to take their own ideas further and make Rightmove a better place for not just ourselves but also our users.