Laughter, stress, the curse of the demo, relief and pride: hackathons are often an emotional rollercoaster. Before my participation in my first two-day hackathon, organized by Deezer last January, I wasn’t sure what to expect. And what awaited me was definitely not a walk in the park.
Since the previous day, the atmosphere of the office had changed. The usual calm of the open space had evaporated to be replaced by a fever pitch. We were full of beans and ready to stay for beers, pizza and the raspberry pi! We didn’t notice when night fell, because the project was taking shape; because it was teamwork; because the demo… was the following day.
I had joined the ranks of Deezer as an iOS developer a few months earlier. It was a small team and I was a little timid at first. For the hack day we decided to spend two days creating an improved experience of the Deezer app for drivers. We presented the project, and recruited a few people who were convinced by the economic benefit underlying such a project. In the end, five of us climbed on board.
Big buttons and rapid access
The idea was simple. We didn’t want to reinvent the wheel, we just wanted to create a simple and fun experience for Deezer users who drive, and allow them to use the iOS app in their car safely. It’s not an easy task, because a phone screen can appear small when mounted on a car’s dashboard, but clicking on the normal version of the app requires precision and attention. As with devices like sat-navs and stereos, interaction with the Deezer app can only be done when the car is stationary in a safe place, so allowing users to do so quickly and easily would make life much easier.
Big buttons providing simple and rapid access to Deezer content: and all on one screen… Over the course of two days, we saw the project take form. For fun, we decided to add a ‘Wake me up!’ button. After an intense couple of days, an interested audience came to see the project presentations. “Who has ever yawned their head off and felt their eyes closing whilst they’re on a long journey?”, asked Erwan, the originator of the idea. “If you click on the new button ‘wake me up’, you’ll get an explosion of music. We’ll select the song from your music based on its beats per minute. You want rhythm, we have it!”. The sound of AC/DC blasted out, whilst we explained that songs with a higher bpm tend to be those thumping beats. The rest of our presentation concentrated on the marketing and business opportunities that the project could offer.
Buckle up!
When we were selected for the second round, we couldn’t believe it, but we were determined to give it our all. Again, we suffered from the curse of the demo… we obviously had some improvement to make on that front. Happily, we kept smiling: being able to laugh at ourselves kept us from going off the road. Regardless, it was clear that people liked our idea. When the winners of the hackathon were announced, we couldn’t believe our luck. The key outcome was the opportunity to develop our idea for real. There were smiles all round. Woo! Buckle up! I hadn’t yet realised that it was the next step in this beautiful adventure that would teach me the most.
Puns aside, we burned rubber organise our next meeting. The idea: to bring together all the contributors who would be tasked with releasing a productionised version of the feature presented during the hackathon. Designers, an agile coach, Android and iOS developers, and a product manager. In fact, nothing was going to happen as we expected. I feel like I’m stating the obvious, this was not a normal kind of project. It wasn’t just a matter of bringing together teams who usually work together: the way of working was new for everyone, and time was short.
Thanks for now!
Everyone was very motivated, but conscious of the limited time available. The die was cast, but the roles and objectives weren’t clear. Should we produce the solution from the hackathon without touching it and release it on iOS and Android? Or should we re-evaluate, based on the logic that an idea developed in two days would need a little polishing. We were divided on which road to take. The week flew by. Day one: we cleared the decks. At the end of the day, some people were still working on the definition of the minimum viable product. Second day: we picked it apart a little. Third day: the same. Were we going to follow the proposals of the designers, or the MVP established by the product team? Development started on the fourth day, when there remained only one and a half days. Mission: Impossible.
The following month of development passed quickly. Despite the motivation of the team and the interest generated by the project, which was palpable, there was a lot of hesitation along the way. Today, car mode is available for Deezer premium users, assuming that they have activated the feature on the Labs page of their iPhone. It’s these users who will give the verdict on the work of the last few months. Will they welcome this simplified mode in the app? For our part, I hope that we will learn from this experience, thanks to our use of user statistics and reviews on the App Store.
Regardless of the outcome, I loved working on this project. The idea of mixing up the teams and agreeing on a short timeframe to release a project went really well. Whatever happens, in my opinion, it provided an awesome chance to get out of my comfort zone and bring benefit to the product, working with new people with differing opinions and ideas, and have a go at driving on the other side of the road. This is exactly the reason that I enjoy coding at Deezer. I hope that we can replace the bonnet again soon, and take lessons from this experience. Thanks for now! It’s an incredible adventure that I’m not ready to forget!
