Last week, I was invited to do a coding dojo for the Java user group in Bergen. I have written a few words about the dojo part of the exercise in a previous blogpost. After “classical” TDD-training, I decided to try something different and gave the group a competition to play with: Extreme startup, a workshop with software created by @rchatley and @mattwynne. The workshop was a huge success and I’m hoping to repeat it soon.
In the exercise, each group creates a bare-bones web server in a programming language of their choice and register its URL with the workshop server on my computer. The workshop server then starts asking each registered web server questions over http.
In the beginning of the competition, the workshop participants don’t know anything: They don’t know what sort of questions will be asked. They don’t know how the workshop server will encode the questions. They don’t know how answers will be scored. They only know that they will get http requests to the URL they registered and they have to work out the rest.
Similarly, I don’t put any requirements on how the participants work. They can decide to work solo, in pairs or in larger groups. They can decide to use TDD or not. They can decide to use any programming language they want. They can even sabotage or spy on each other.
I decided to officially end the coding dojo before the competitive exerice. This way, people could decide how long they wanted to stay and how involved they wanted to be.
As teams start answering questions, the scoreboard on the projector starts showing some teams doing better than others. After a pretty short time, @ovegram and @idarborlaug gained an advantage that they held throughout the night. Some people used tests and some did not. Some people quit early and some kept going. @StClairJohn and @karianneberg both showed remarkable stamina and kept working after everyone else had called it a night. Eventually they gaining the lead.
Take-aways: The competitive aspects and the open format made this into an extremely successful exercise. Many of the participants were not very familiar with the web-APIs of their platform, so having @bodiltv‘s collection of starting points helped people focus on the exercise, instead of the technical details. Having a real-time problem to work on forced people to balance quality and speed. Many teams considered using TDD and some did. Some benefited a lot from their tests, some might have been hurt by them. Some teams spotted problems using their tests, while one team forgot to run all their tests and ended up having a bug in production for a long time, while they had a test that could’ve saved them if they’d only run it.
One especially enjoyable aspect of the exercise was that the participants helped out other teams quite a bit. I waited with adding more questions until everyone was ready, so the leading players were interested in helping those lagging behind. I hope that in future iterations, there will be even more cooperation between teams.
@ovegram and @idarborlaug set up their working environment to ensure that they knew what happened “in production” all the time. As they were in the lead, I convinced one of the other players to sabotage them by stopping their server while I distracted them. They detected the sabotage within one minute, due to the way they set up their IDE.
There was one question where we believed for a long time that there was no correct answer. This was actually a good opportunity to discuss the problem of choosing your battles. Some customers will never be satisfied, so trying to please them is a waste of time. Recognizing impossible questions is a good lesson from the exercise. Even if it turned out in the end that the question did have an answer.
Extreme startup experiences (mostly for Robert and Matt): The extreme startup server is very cool. The questions are good, and I’m looking to add some of my own as well. Teams who had weak skills with regular expressions were often penalized, while no other skill were as essential. To add a different aspect to the game I would very much like to see (or add) some questions that require the servers to maintain state for client sessions.
Another weakness of the exercise is the fact it’s very hard for people to catch up when someone has a big lead. One possible modification would be to add situations where a single screw-up would cost someone a huge number of points, especially if they were already in the lead. Alternatively, if each round gives 10x the points of the last round, an early advantage will not carry for long.
It was a bit difficult to set up the workshop server on a Windows machine, mainly due to Ruby gems with native extensions. The server depends on a version of the library
eventmachinethat doesn’t compile on Windows, so I had to upgrade this. I updated the README and Gemfile in my fork for extreme_startup to describe how also get it to work on Windows.
Extreme startup is a very fun workshop and it is quite easy to run. I will definitively run it again at future workshops. The exercise lets you put your practices to the test. Your score will not depend on whether you did do things by the book or not. If you get a good score and didn’t use TDD, that’s fine. If you got a good score and did use TDD, that’s fine, too. If you wrote beautiful code, but failed to answer the questions, you still lose.
I hope that this blogpost inspires you to seek out or organize your own extreme startup workshop!