Technology Blog

A few weeks ago 4 developers from our team went up to the Museum of Science and Industry in Manchester to take part in Hackmanchester. This 24 hour coding competition was designed to get teams from various companies, user groups and universities to build a product or investigate an idea, in 24 hours, to meet various challenges.

We sponsored the event as we thought it was a good place to gain exposure both for our consumer brand and for our development team. We’ve struggled in the past to hire decent developers and spreading our catchment further north seemed to make sense.

Winning…

To cut a long story short, we won the challenge that we entered, as offered by Esendex

We want to see our simple APIs used in smart ways. We’ve got a handy Push Notifications service for receiving messages and status updates, and a REST API for sending (and everything else). Come up with a clever way of using them and there’ll be a cool prize for you and your team!

You can see the result of our labours on AppHarbor or in the expertly narrated demo video since we’ve turned the API key off now. We also conducted an interview for Esendex with a picture of the team displaying our well received prizes.

…with a Sustainable Pace

I don’t propose that we had some secret to winning but found that we weren’t as stressed, tired or panicked as other teams and we believe that was due to the way we worked during the event. We followed practices that we use every day, and that we know work well.

Early on we decided that it was folly to expect us to stay awake for 24 hours and still produce a quality product. Instead we decided to opt for a rough 2am deadline to go back to the hotel for sleep, before continuing the next day after breakfast. We also ensured that we had breaks for food and regular stops to the copious fruit, squash and sweet supplies. While some teams stayed awake all night long they said that they produced terrible code in the early hours, argued more, and changed direction due to lack of confidence. We maintain the quality of our code through ensuring we could focus and make clear decisions by calling it a night at 2am. We follow a practice of sustainable pace at work too, discouraging anyone from working late or at weekends and ensuring releases are done within set hours.

Release Early, Release Often

Our CI and Coding Setup

We had a working skeleton out within 40 minutes – it only had a “hello world” web page on it but it proved that we could easily commit changes and have them appear on our host. AppHarbor also provided a build history and post commit hook, which is why it was chosen initially. Now every commit would be built, tested and deployed allowing us to release roughly every 5 minutes. This constant integration and feedback meant we didn’t build on broken code and all commits could be tested. We used a Nexus 7 as a continuous integration monitor showing the build results on AppHarbor so we could react to any broken integrations – the key was visibility.

Prioritised Backlog

Before any code was written we’d discussed and written up, on simple index cards, the features that we thought we could build. We originally decided on two sites, both SMS driven, one for football and one for music, but once we’d prioritised the features we found we could provide more value by adding features to one site then by having two. It also simplified the architecture of the site, allowing us to deploy the web front end and API in one. We reviewed the features and priorities at regular intervals (roughly 4 hours) and had a code freeze 2 hours before the end of the programming session. The code freeze meant we could polish up the interface, fix little niggles and prepare demonstration too. Although we try to separate services during our day jobs, we do prioritise features and hold code freezes during times of high risk.

Pair Programming

A practice we couldn’t do without on the day was pair programming. The sharing of knowledge and ideas when building something some quickly meant we could add features quickly. As the night wore on it was also great for spotting mistakes and maintaining focus. We organised our pairs to play to people’s strengths too. I heard one team say they didn’t work well together as they were in different teams when at work – but so were we; 2 from the Locker Team, 1 from Media Delivery and an Assistant Director of Technology.

Simple Services over Tests

Although we had a test project early on we didn’t use test driven development. We started to regret this as the application got more complex and we’d started to introduce small bugs later in the day. We decided that keeping the services simple, and sticking to separation of behaviour should allow us to make changes with confidence.  The most risky part of the testing was the sending and receiving of SMS so decided not to automate that and simply use our application instead. This gave us the added benefit of user feedback as a side effect of our need to manually test it. As the code was to only live for 24 hours it made sense that we’d be able to cope with that risk but since we were asked to pass on our code for the Junior Hackmanchester attendees we wished we’d used TDD as the codebase would have been much easier to work with for newcomers. It also meant we did not refactor the code as much as we should have due to the additional cost of manual testing.

Conclusion

We’ll definitely be attending similar events again. We found they are good tests of both your programming and organisational ability. It might be good to adopt other practices and drop some we tried here to see if it makes a difference for such an event. We’ve also started working with Esendex and their local university to sponsor a code quality prize for their project module, more on that later.

This entry was posted on Tuesday, December 11th, 2012 at 5:29 pm and is filed under Agile, Community Events, Planning. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.