Thinking Inside a Bigger Box

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 eventmachine that 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!

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I chose a format that let people work more independently rather than the classical style of “lots of people passing the keyboard around and looking on the code on a projector”. The result was an informal, competitive and engaged workshop where people continued playing with the exercise long after the official program was over. While drinking and socializing, of course.

I found the format useful, and perhaps this blogpost will useful to others who would like to organize a coding workshop.

Part I: A longer introduction

In order to get people to have a shared vision of the activities of the workshop, we started slower than I’ve sometimes seen in other workshops. First, everyone in the room said a few words about what they were hoping to get out of the evening. Then, I demonstrated a simple exercise together with @karianneberg. In the exercise, we demonstrate how to do pair programming and test-driven development. After the demo, we discussed what aspects of this way of working were surprising or different from what the audience was used to.

Take-aways: Coding dojos often throw the participants out on deep water right away. By instead showing an idealized pair-programming session, we provided a model for the participants to follow.

Part II: Exercise

We started out with the simplest programming exercise I’ve been able to come up with: Calculate whether a year is a leap year. I took the instructions for of the exercise from @jonjagger‘s Cyber Dojo tool. The participants worked in pairs on this exercise.

Cyber Dojo can be a frustrating tool, and I offered people the option to use it or not as they wanted. In the end, almost all the pairs chose to use it for the first exercise. And we could see how their work was progressing on the projector.

After everyone had completed the leap year exercise, we switched around the teams and worked on an exercise to translate Arabic numerals to Roman numerals. Here, too, I used the instructions from Cyber Dojo. However, due to various problems, we decided not to use Cyber Dojo as the programming environment for this exercise.

We did a brief retrospective after each exercise. I decided to mostly use this chance to ask “too much or too little questions”, like “do you feel it would’ve been faster if you’d taken larger or smaller steps?”, “do you think you refactored too early or too late”, “did you switch which person in the pair was using the keyboard too much or too little”, “did you spend too much or too little time thinking about how you would solve the problem”, etc.

Take-aways: Coding dojos usually practice a stylized form of programming with as small steps as possible. By reflecting on how it would be to work with the same problem in a less forced way, it’s easier for people to find out how they can apply what they learn to their day-to-day work. In particular, the discussion about how big the TDD-steps should be brought up a lot of interesting debate.

I usually try to have bigger exercises, like Yahtzee scoring or Poker hands. I found the smaller exercises to work very well for this workshop as this part ended up acting as a warm-up for the competition.

Cyber dojo experiences (mostly for Jon): I’ve used the Cyber Dojo a few times now. It’s an interesting tool, and I find Jon’s idea about taking away features to avoid distractions to be a good strategy in general. However, I usually find that to some level, the tool becomes a distraction because of its limitations. In particular, I think the groups would’ve wanted to continue using it if they didn’t have to work so with the build script and if they could’ve switched between files and run the tests using the keyboard. The groups miss code completion etc, but are willing to accept these shortcomings because of the community and competitive aspects of the tool.

The real killer, however, was the setup. Using a Windows box, I didn’t get the Cyber Dojo to run natively. I tried using a VirtualBox setup, but kept running into technical problems. In the end, I decided to risk using Jon’s hosted dojo at http://cyber-dojo.com. Sadly, it turned out that Jon was doing upgrades of that system halfway through our dojo. Too bad, but as he provides this service out of the goodness of his heart, I knew the risks.

Part III: Competition

After the exercises, we had a competition where people got to use or ignore what they’d learned as they saw fit. The competition used the Extreme Startup workshop. There’s a lot to be said about it, and I’ll write a future blogpost on Extreme Startup.

Conclusion

Cyber dojo and extreme startup both create a competitive and social environment for small groups to practice programming. This can create really fun workshops. The Bergen Java User Group kept playing with Extreme Startup until midnight.

I will use Extreme Startup as a workshop in the future. Hopefully I will add more questions, too. I may use Cyber Dojo again, but I’m hoping for some changes to the software before doing so. As it is, there are too many aspects that distract the users.

For those of you who already use PuTTY: Here’s a little improvement that’s surprisingly little known. Probably because it is very hard to explain. But I’ll try.

Here is how you can avoid starting programs, entering login information or indeed typing passwords when you use PuTTY:

1. Download Putty installer from the PuTTY Download Page. Make sure to grab the “Installer”
2. Install Putty
3. Start PuttyGen from Start -> PuTTY-> PuttyGen
4. Generate a new key and save it as a .ppk file without a passphrase
5. Use Putty to login to the server you want to connect to
6. Append the Public Key text from PuttyGen to the text of ~/.ssh/authorized_keys
7. Create a shortcut to your .ppk file from Start -> Putty to Start -> Startup
8. Select the .ppk shortcut from the Startup menu (this will happen automatically at every startup)
9. See the Pageant icon in the system tray? Right-click it and select “New session”
10. Enter username@hostname in the “Host name” field
11. You will now log in automatically.

This process is a bit hard to explain, so I have made a short video that explains it:

In order to streamline things even more, notice how Saved sessions show up under the Pageant icon in your system tray.