This post is over 6 months old. Some details, especially technical, may have changed.

Hackathon Retrospective

So my first ever Hackathon (48hr) is done and dusted and has been for over a week (lazy!!). All in all it was a great experience and plenty of stuff was learnt - we got some technology evaluation (good and bad), ways we could streamline the process and things that burnt time way too fast.

This event was intended as a kind of dry run to see if there is any benefit in Kainos running more events of this nature. Perhaps external ones for charity or educational endeavor. Does that mean I'll be doing it again? Hope so. I guess the best question to ask then is what did I want to get out of it. Well I went in a bit open minded - mainly I wanted to have the experience but I also wanted to try and get some of the techs I have been tinkering with and see how they faired in a semi-real life environment. I think I actually wanted to have produced something really usable too but perhaps I was expecting too much? I mean what we produced wasn't a total failure but it needs a lot of work.

The End Result

We ended up producing a web app for giving continuous feedback to colleagues. The idea was to allow people to give and ask for feedback as well as facilitating a more formal career review workflow. Social appraisals as it were.

We had some basic features such as integrated Windows Authentication and user information look up etc, autocomplete on peoples name, pretty relative time output and some commenting features. So yeah it's pretty sparse but hey it's a start. Whats more interesting is the process and things we observed.

The Story

The team was a mix of Technical Architects, placement students, software and senior software engineers and even a project manager we had a few no shows and a few people who intended to drop in for a while and leave again. We also had a person who thought going out the night before was a good idea - it wasn't (hahaha sucker). But hey at least he showed up. I have no problem with people not turning up as long as they let someone know but not turning up and not telling me…. bad form folks.

Anyway the majority of us gathered in our office at 9ish on Saturday morning and started pitching ideas to attempt. We ended up with a decent pile of good ideas and started aggressively throwing ideas in the bin until, after some debate, we ended up with the one we decided to run with. After that we started thrashing out user stories as a group and ended up with a decent amount. The whole process, including getting food, took about 3 or 4 hours. We then all got stuck into various tasks, I started getting the build server functioning, a few people sat with the product owner and started fleshing out the user stories, a few people looked at the domain model and some people started writing acceptance tests. This was the bit that cost us a lot of time. Rather than each person or group working on vertical slice through the system we went horizontally and started arguing over things that never even made it into the end solution. Everyone fell into their comfort zone cause thats the way Kainos projects typically run - old school waterfall for the most part. So yeah no REAL work actually got done, people were just keen to start and I didn't really pull it under control until it was just too late . It would have been nice to have a Scrum Master type person who was overseeing everything too. I was too busy doing my own horizontal slice :-S.

So things went on like this for a while, a lot of "getting things in place" and some people had to drop off. Eventually we hit a point when we realised that our rate of work was nowhere near what it should be and something needed to change. At about this point everyone but me decided to get some shut eye and I slipped my headphones in, played some Bon Iver and got stuck into fleshing out what we already had. This formed the basis of the work the next day (this was about 4AM on Sunday morning) when the remaining team (5 left out of the initial 12) kicked of the final leg. Due to our earlier stumble there wasn't very much for our product owner/tester to do for most of the day which was a shame. Eventually we ended up with what you seen above (finishing up at about 6PM on Sunday night). The Sunday was less frantic, lots of pairing, lots of trying new technologies and was so much more productive

The Technologies

We used quite an interesting array of technologies

In terms of supporting technologies we used the awesome AgileZen for our Kanban board and HipChat for some shared chatting (we had Lync but it's inability to persist conversations is a deal breaker in my book). Finally, we used TeamCity as our build and continuous integration server which was a much much better experience than CC.NET

Hackathon Review

I guess my story above probably sounds more negative than it really was cause thats the way I write. It wasn't - it was great craic. We held a review post-hackathon with everyone involved and the following point were raised.


  1. Experience with new technologies e.g. CoffeeScript, PetaPoco
  2. Experience with things such as user stories, kanban etc.
  3. People got to do things that they just don?t get the chance to do. E.g. Andrew was designing screens.
  4. Pair programming
  5. Great craic!


  1. People didn't know what to do when there were bottlenecks
  2. Lunches and dinners were taken at different times. This affected communication.
  3. People thought they weren't productive with no/little sleep.
  4. Tester/Product Owner wasn't used as much as they could've been on the second day.
  5. Facilities room has a motion sensor on the lights
  6. A yoga mat is not good for sleeping on


  1. Add an equivalent of a Scrum master to the team.
  2. Agree an idea prior to the hackathon so it doesn't eat into dev time.
  3. Create a couple of use cases going into the hackathon so the dev team don't have to wait on the business people
  4. Set up infrastructure prior to the hackathon
  5. Choose a few technologies before hand so that people can learn a bit about them before. e.g. the software for source control can be decided in advance.
  6. Make sure people aren't going to the shops/getting food at different times
  7. Clone James for tech leader/troubleshooter/developer
  8. Have less team work. We found that the entire team was focused on some tasks that didn't require it because, well, teamwork is great.
  9. Focus on core functionality instead of e.g. logins which can be done later. Or prep login functionality before.
  10. Use hackathon specific machines
  11. If there's another weekend hackathon, people should go get some sleep to rest eyes and minds!

So all in all it was a great learning experience and I don't think anyone said "I'm never doing that again" which was a result and I am certain we will attempt something else in a similar vein and take on board all those improvements to produce something that changes the world or something. So many things to try…. what you all doing next weekend :-P

Published in Craftsmanship on August 28, 2011