In this first blog post, I will address the first two of these questions: Why do we run CodeFest? and How do we run CodeFest?
And so it came to pass that on the 5th of December 2014, NCR Edinburgh's CodeFest Winter 2014 drew to a close.
In the spirit of continuous improvement we ask ourselves questions such as How successful was CodeFest? and What are the lessons to be learned for future CodeFests?
In order to answer these questions we need to understand why and how we undertake CodeFest as well as what happened during CodeFest Winter 2014.
Mike has already blogged on the merits of CodeFest, but it is worth restating what CodeFest is and why we do it.
At NCR Edinburgh the definition of CodeFest is:
Two days and your imagination. Form a team (size from one to many) and build a software/hardware solution to a problem. It can be the software/hardware that you find interesting, or the problem space, or both. At the end of the two days demo the solution to your peers.
In other words: for four days every year (two in Summer and two in Winter) we let the team off the leash to remember why they got into the software business; surprisingly the reasons for their career choice don't tend to revolve around aspects such as the pure practice of the agile methodology, but are more about solving interesting problems (for a given definition of interesting; as you'll see in the second part of this blog post).
I took over the running of CodeFest in early November and started planning the upcoming Winter 2014 run.
Previous CodeFest iterations had been successful but, with the above definition niggling away at me, I felt there was still some room for improvement.
Inspiration struck, as it tends to, in the wee small hours: what we needed was a lightweight process surrounding the two days itself; a process that would build up to the crescendo of CodeFest, generating interest and enthusiasm, and then would manage the inevitable post-CodeFest come down.
In essence we needed a process to maximise the happiness of CodeFest!
And with that thought ringing in my mind, the technical part of me hung its head in shame.
After many whiteboard sessions and sleepless nights, the following six-step lightweight process for CodeFest was born:
Any similarity to dystopian political systems codified in contemporary YA-fiction is purely coincidental and is most probably the result of the reader's overactive imagination.
The aim of The Proposing is to give each project proposal the oxygen of publicity and in doing so create a burning desire within the team to see the proposals become reality.
Projects can be suggested by anyone in NCR Edinburgh. Each project proposals is succinctly described by its proposer (elevator pitch style) on the internal CodeFest wiki in preparation for The Proposing process.
Three weeks before The Coding is due to start our weekly code and cake sessions are taken over by the proposers. Each proposer attempts to win over their peers with their project proposal(s) through the medium of a two minute presentation followed by two minute Q&A session.
The Grading is where the team express their desire to work on the projects. The output of the Grading feeds directly into The Winnowing and The Favouring steps.
One week before The Coding each member of NCR Edinburgh, enthused by The Proposing, stack ranks the proposals according to how happy they would be to work on the proposal.
The Winnowing applies the output from The Grading to the proposal pool defined in The Proposing to reveal The Seven proposals that will be promoted to fully fledged CodeFest projects.
The Winnowing is more than just the simple exercise in applying the cold hard figures generated by The Grading; it also takes into account more esoteric concerns such as proposal worthiness. It does this through The Five: a panel selected at pseudo-random from the NCR Edinburgh team.
The Five meet four days before The Coding, and their deliberations produce The Seven.
The Favouring process creates the teams for each of The Seven projects chosen by the Winnowing.
The aim of the Winnowing and the Favouring is to maximise the potential happiness of the CodeFest project teams.
Three days before The Coding, the project teams are announced.
With the build up complete and maximal happiness all but guaranteed, the teams start on their two days of coding.
Some project teams will have met in the three days between The Favouring and The Coding to plan their strategy for success; others will trust to their skills that they can hit the ground running.
The output from The Coding will be the project demos which will be used to assess the worthiness of each project team in the eyes of its peers.
And at the end of the second day of The Coding, the project teams come together to display the fruits of their labours and to feast on the fruits of their competing teams. Prizes are given, banter is exchanged and the end-of-CodeFest celebrations begin.
It is during The Melding that we remember that, at the end of the day, we became software engineers because when presented with a puzzle, our eyes light up and we're unaware of the passage of time as we strive to the solution. As engineers we put process around this to ensure that the solution we produce is worthy of being released to the world, but at the heart of our day-job is the problem solving that makes us who we are.
Part 2 of this blog post will cover what happened at CodeFest Winter 2015.