At Plumbee we still consider ourselves to be a startup. Although we’ve grown rapidly I believe that we’ve managed to maintain a good degree of flexibility, and a high quality of people.
To test our ability to be flexible I decided to run Robert Chatley’s “Extreme Startup” workshop. The workshop requires the participants to respond in realtime to a changing market. Over the course of the workshop each team must get their code up and running and then use it to answer questions being asked by a central server. The central server acts as the marketplace and dictates the pace of the evening (under control of the organiser); firing off questions of increasing complexity and awarding points for correct answers.
The result is that the participants are coding rapidly to keep up with changing requirements. Standing still for too long is not an option, as the selection of questions changes over time and the participants have no control over what questions they will be asked, or when. Responding with the wrong answer, or failing to respond at all both result in points being deducted. At the end of the session, the team with the most points wins. To up the stakes, a bottle of Champagne was offered as a prize for the winning team (although we had beer and pizza freely available throughout the evening as well).
Although it is only a rough analogue of running a real startup, it is a very real test of one’s approach to rapid development. It’s also a lot of frantic fun.
The Extreme Startup Server
Each “Startup” team registers their server with the central marketplace server which maintains a graph of everyone’s scores. To keep people on their toes, the game comes with several rounds of questions. The rounds can be manually advanced using an administration page on the server and you can either choose to tell the players that this has happened, or let them respond to the new questions that they see in their own time.
Technically, the game was played over HTTP. The Extreme Startup server has a registration page allowing teams to register their own server URLs. After that it’s a matter of being able to parse the query string of the requests and form a suitable response.
A simple diagram of the Extreme Startup server in action.
It’s one thing to be able to write clean, well-tested code, but another to rapidly set up your own server and hack together some quick and dirty string parsing code. Luckily the central server comes with a “warm-up” phase that lets people get up to speed before awarding points that count towards the final score.
GET /?q=042898e0:%20what%20is%20your%20name HTTP/1.1 Connection: close Host: localhost:3003
tcpdump output showing the warm-up question arriving in the query string of a GET request.
Another useful feature of the Extreme Startup server was the Log page. Each question was sent with a short code, and the Log page allowed you to match up the questions you’d seen with the points awarded for your response.
The Log page for “Team A” on the Extreme Startup server, showing the points awarded for failing to respond, responding, and then responding with the correct answer.
There’s also a repository of example servers in over a dozen different languages to help people get started, although all of the teams at Plumbee chose to build their own. The registration process requires that a full URL including the scheme (“http://”) be provided. This led to one of the teams initially being unable to successfully register. Once understood, the problem was trivial to fix. To help mitigate this problem in the future I added some placeholder text to the registration form and created a pull request for the original repository.
New player registration, with the URL placeholder text circled.
The participants divided themselves into teams of two or three people. This was to ensure that everyone would get enough time at a keyboard during the evening. Over the course of a few hours the teams wrote code that they weren’t proud of, favouring speed over quality. When I asked to see people’s code at the end, it always came with a health warning!
One of the main differences between this exercise and what we normally do was the shift of focus towards immediate results. If you know that you don’t have to maintain the code going forward - or even remember how your code works tomorrow - then you can take risks that wouldn’t normally make sense. For example, none of the teams wrote tests for their code, and most of the code was structured as a single long method. Time spent refactoring was time that could have been spent writing answers for more questions.
I advanced the rounds quite aggressively, as I wanted to maintain that “flying by the seat of one’s pants” feel for the teams. This meant that there were almost always question types that each team could work on answering.
After a while, some very tricky questions started to arrive, including one asking for the Queen’s mobile phone number, and another question in two parts split over two separate HTTP requests. At first I thought that this was simply the later rounds ramping up the difficulty. However, it turned out that there was a more surprising explanation.
One of the teams had noticed that their opponents’ URLs were visible on the server. They had decided, in a spirit of competitive mischief, to start curl-ing decoy questions at other team’s servers! It was certainly a creative approach to solving the problem.
I considered intervening at this point, but everybody seemed to be having a good time, and the other teams quickly worked out what was going on.
In the end I advanced the rounds too quickly and all the teams ended with a negative score (having lost points for incorrect answers). However, there was one team that had consistently held the lead for most of the game and finished ahead of the others (with only -985 points!). I awarded them first place.
What did we learn?
Over a glass of chilled Champagne, we discussed the game. Everyone had clearly enjoyed the experience. As an exercise in having fun it had certainly worked judging by the smiles on people’s faces. While everyone appreciated the need to work quickly for this game, some reported that trying to work too quickly had in fact slowed them down. Experimenting with Scala’s regexes had also delayed one team.
Perhaps the most noticeable aspect of the teams’ code was how simple it was. No additional layers of abstraction had been created. Few helper methods existed, but those that did had clearly defined single responsibilities. The code certainly wasn’t over-engineered, although it tended to contain repetitive sections for checking strings to see which question was being asked.
I learnt that some of my colleagues can be quite inventive when it comes to winning. They had used information available to them to tilt the playing field to their advantage. When it comes to a friendly coding game in the office it seems that bending the rules is par for the course.
The exercise had also demonstrated the value of teamwork. Tasks were divided between team members so that while one person was writing code to detect a new type of question, another would be searching online for existing algorithms to answer it. Working as a team is something that I think we do particularly well at Plumbee, and it was good to see this during the evening.
If you know a group of programmers who might enjoy a bit of competitive coding, I’d highly recommend this exercise. There’s nothing like a bit of time pressure and the possibility of beating your friends to get people focused and enjoying themselves.