Creating legacy behavior in 15 minutes

Today I was the facilitator of our local Code Retreat event in Karlsruhe at the Global Day of Code Retreat 2013. In session 4 – the first afternoon session – I set the following constraint

Solve the problem as quickly and dirty as possible. Do not write clean code, do not create a good design, just forget anything you’ve ever learned about inner code quality. Simply get this thing running!

The pairs started to hack and it was really funny to see all the bad code appearing on the screens. After 15 minutes I said “hands up” and got the attention of the group. I told them, “unfortunately a flu is in town and half of the team will be gone for a while. The pairs chose who had to leave and I took them with me out of the room while telling the remaining guys, “just continue on your own, the product has to be finished soon.”

I told the leavers that they are going to switch pairs in a minute and return into the room as the very best clean coders one could imagine. They were newly hired and now have the responsibility to do something for software quality, testing, and clean code.

The results were remarkable!

Many of the teams have not been able to transform the messy code of the first 15 minutes into something tested and understandable within the next 25 minutes. Some of them were caught by the “broken window” effect – there was already enough dirt in the code that they simply followed that way and quickly created more dirty code. One of the most interesting observations was the behavior of the “old” developers of the pairs. They almost fought for their crappy code and really resisted to transform it into something more clean. In reality this is exactly the “this is how we always have worked here”-symptom.

If you setup a session with this activity during a Code Retreat, I would be very interested in the results and your findings.