Coding Is Like Cooking

A little while back I was back in Stockholm facilitating another Code Retreat, (see previous post), this time as part of Global Day of Code Retreat, (GDCR). (Take a look at Corey Haines’ site for loads of information about this global event that comprised meetings in over 90 cities worldwide, with over 2000 developers attending.)

I think the coding community could really do with more people who know how to do TDD and think about good design, so I’m generally pretty encouraged by the success of this event. I do feel a bit disappointed about some aspects of the day though, and this post is my attempt to outline what I think could be improved.

I spent most of the Global Day of Code Retreat walking around looking over people’s shoulders and giving them feedback on the state of their code and tests. I noticed that very few pairs got anywhere close to solving the problem before they deleted the code at the end of each 45 minute session. Corey says that this is very much by design. You know you don’t have time to solve the problem, so you can de-stress: no-one will demand delivery of anything. You can concentrate on just writing good tests and code.

In between coding sessions, I spent quite a lot of effort reminding people about simple design, SOLID principles, and how to do TDD (in terms of states and moves). Unfortunately I found people rarely wrote enough code for any of these ideas to really be applicable, and TDD wan’t always helping people.

I saw a lot of solutions that started with the “Cell” class, that had an x and y coordinate, and a boolean to say whether it was alive or not. Then people tended to add a “void tick(int liveNeighbourCount)” method, and start to implement code that would follow the four rules of Conway’s Game of Life to work out if the cell should flip the state of its boolean or not. At some point they would create a “World” class that would hold all the cells, and “tick()” them. Or some variant of that. Then, (generally when the 45 minutes were running out), people started trying to find a data structure to hold the cells in, and some way to find out which were neighbours with each other. Not many questioned whether they actually needed a Cell class in the first place.

Everyone at the code retreat deleted their code afterwards, of course, but you can see an example of a variant on this kind of design by Ryan Bigg here (a work in progress, he has a screencast too).

Of course, as facilitator I spent a fair amount of time trying to ask the kind of questions that would push people to reevaluate their approach. I had partial success, I guess. Overall though, I came away feeling a bit disillusioned, and wanting to improve my facilitation so that people would learn more about using TDD to actually solve problems.

At the final retrospective of the day, everyone seemed to be very positive about the event, and most people said they learnt more about pair programming, TDD, and the language and tools they were working with. We all had fun. (If you read Swedish, Peter Lind wrote up the retrospective in Valtech’s blog) This is great, but could we tweak the format to encourage even more learning?

I think to solve Conway’s Game of Life adequately, you need to find a good datastructure to represent the cells, and an efficient algorithm to “tick” to the next generation. Just having well named classes and methods, although a good idea, probably won’t be enough.

For me, TDD is a good method for designing code when you already mostly know what you’re doing. I don’t think it’s a good method for discovering algorithms. I’m reminded of the debate a few years back when Peter Norvig posted an excellent Sudoku solver (here) and people thought it was much better than Ron Jeffries’ TDD solution to the same problem (here). Peter was later interviewed about whether this proved that TDD was not useful. Dr Norvig said he didn’t think that it proved much about TDD at all, since

“you can test all you want and if you don’t know how to approach the problem, you’re not going to get a solution”
(from Peter Siebel’s book “Coders At Work”, an extract of which is available in his blog)

I felt that most of the coders at the code retreat were messing around without actually knowing how to solve the problem. They played with syntax and names and styles of tests without ever writing enough code to tell whether their tests were driving a design that would ultimately solve the problem.

Following the GDCR, I held a coding dojo where I experimented with the format a little. I only had time to get the participants do two 45 minute coding sessions on the Game of Life problem. At the start, as a group we discussed the Game of Life problem, much as Corey recommends for a Code Retreat introduction. However, in addition, I explained my favoured approach to a solution – the data structure and algorithm I like to use. I immediately saw that they started their TDD sessions with tests and classes that could lead somewhere. I feel that if they had continued coding for longer, they should have ended up with a decent solution. Hopefully it would also have been possible to refactor it from one datastructure to another, and to switch elements of the algorithm without breaking most of the tests.

I think this is one way to improve the code retreat. Just give people more clues at the outset as to how to tackle the problem. In real life when you sit down to do TDD you’ll often already know how to solve similar problems. This would be a way for the facilitator to give everyone a leg-up if they havn’t worked on any rule-based games involving a 2D infinite grid before.

Rather than just explaining a good solution up front, we could spend the first session doing a “Spike Solution”. This is one of the practices of XP:

“the idea is just to drive through the entire problem in one blow, not to craft the perfect solution first time out.”
From “Extreme Programming Installed” by Jeffries, Anderson, Hendrickson, p41

Basically, you hack around without writing any tests or polishing your design, until you understand the problem well enough to know how you plan to solve it. Then you throw your spike code away, and start over with TDD.

Spending the first 45 minute session spiking would enable people to learn more about the problem space in a shorter amount of time than you generally do with TDD. By dropping the requirement to write tests or good names or avoid code smells, you could hopefully hack together more alternatives, and maybe find out for yourself what would make a good data structure for easily enumerating neighbouring cells.

So the next time I run a code retreat, I think I’ll start with a “spiking” session and encourage people to just optimize for learning about the problem, not beautiful code. Then after that maybe I’ll sketch out my favourite algorithm, in case they didn’t come up with anything by themselves that they want to pursue. Then in the second session we could start with TDD in earnest.

I always say that the code you end up with from doing a Kata is not half as interesting as the route you took to get there. To this end I’ve published a screencast of myself doing the Game of Life Kata in Python. (The code I end up with is also published, here). I’m hoping that people might want to prepare for a Code Retreat by watching it. It could be an approach they try to emulate, improve on or criticise. On the other hand, showing my best solution like this is probably breaking the neutrality of how a code retreat facilitator is supposed to behave. I don’t think Corey has ever published a solution to this kata, and there’s probably a reason for that.

I have to confess, I already broke all the rules of being a facilitator, when I spent the last session of the Global Day of Code Retreat actually coding. There was someone there who really wanted to do Python, and no-one else seemed to want to pair with him. So I succombed. In 45 minutes we very nearly had a working solution, mostly because I had hacked around and practiced how to do it several times before. It felt good. I think more people should experience the satisfaction of actually completing a useful piece of code using TDD at a Code Retreat.

Scandinavian Developer Conference will be held in Göteborg in April, and last week we launched the detailed programme on the website. I’ve been involved with the conference ever since the first event in 2009, but this year I’ve taken on increased responsibilities, acting as Programme Chair.

When P-A Freiholtz, the Managing Director at Apper Systems*, (the company behind the conference), approached me about taking this role, I jumped at the chance. My business is all about professional development for software developers, and a conference in Göteborg is a really good opportunity for a lot of local people to hear about what’s going on in the world outside. Many of the developers I meet in my work don’t often get away from their desks, spending the majority of their time caught up in the intrigues and deadlines of a single project and company environment. SDC2012 will be a chance for a lot of local people to broaden their horizons without it costing their boss a fortune, or disrupting their usual schedule too much.

I wrote an editorial on the front page of the conference website which explains more about what’s on the programme and who should come. Everyone involved in software development, basically 🙂

These days, we compete in a global marketplace for software development. I’m hopeful about the future, I’m enthusiastic about Swedish working culture, and I think Scandinavian Developer Conference is helping Göteborg grow as a center of competence. Please do join us at the conference.

* formerly named Iptor – now under new ownership.

At a conference about software development, wouldn’t it be useful to have some people there actually develop software? We want to invite you to bring your whole team, and show off how agile you are. Set up your team information radiators, pair programming stations and servers, and spend part of the conference actually developing your product! With any luck, some of the excellent agilists at the conference will come and pair with you.

The only rules are that you must be agile, and you must deploy into production during the conference. If you deploy several times a day and the product is generally available for conference delegates to use and try the new features, all the better. 🙂

See this as a challenge for your team. If you’re going to be able to show your process off to a whole conference of agilists, wouldn’t you like to have the best possible process? Wouldn’t you like all your team members to work effectively with the latest tools and techniques? Wouldn’t the challenge of having to be ready to show off what you can do at XP2012 be a great way to motivate your team to improve over the next 6 months?

This is the challenge that the team behind http://blocket.se (one of Sweden’s biggest ecommerce sites), and a team from SAAB Gripen, (software for jet fighters), have already accepted. Will you join them, and take up the XP2012 team challenge?

At XP2011 we introduced a new kind of presentation – the tech demo. The idea was to give people 30 minutes to demonstrate a new tool or technique. For example, some people performed code katas in diverse languages, and others showed various productivity-boosting frameworks.

For XP2012 we want to continue with these kinds of demos, but with an additional rule. You can’t touch the keyboard yourself when you present. We want you to co-present with someone else, drawn from the audience, who will do the typing and demonstrate the tool or technique. Your job is to coach them into doing the demo you’ve planned, and to explain to everyone what’s going on.

Your co-presenter could be someone drawn from the audience who you’ve never met before. You’ll have to expertly coach them into demonstrating what you aim to show to the rest of the audience. If you choose this route, it will certainly be a big test of your skills of coaching and pedagogy.

Alternatively you can come to the conference and find a volunteer in advance of the presentation. You could make time for a practice run or two before the presentation. Again, you’ll be showing not only your tool or techique, but also how easy it is for a good programmer to learn.

If you’re thinking this sounds like an awfly scary way to do a demo, then you may be right. We think it’s also a very good way to have demos that engage the audience and really show off what you’re capable of.

If you know someone else who’ll be at the conference you could of course prepare the demo with them well in advance. You’d be able to work out exactly what pitfalls they will fall into, and have a slick commentary ready. Just having one person typing and the other talking is a great advantage in a demo, and this would probably still be good to watch. It might not be quite as challenging though 🙂

Will you accept the XP2012 Tech Demo challenge?

The Call for Papers for XP2012 is currently open, and this year we’re doing things a little differently*. I’m one of the co-chairs responsible for programme design, and also involved in reviewing session proposals. (You might be interested in my post about XP2011, which I was also involved in organizing)

Most proposals are going through what will hopefully be a more transparent, agile and effective review process than we’ve had in the past. The idea is that everyone sends in a first draft proposal, and then receives feedback from reviewers who want to help them to improve and refine their ideas. When everyone has had a chance to act on this feedback, the review committee will select the proposals that will be put on the programme for the conference.

More information, dates and benefits of speaking are listed on the conference website. My next two posts contain more information about a couple of the session types we’re looking for: Tech Demos
and the Team Challenge.

*Academic papers have a separate review track, and proceed much as they have done previously. The demands of academic rigour and peer review mean we won’t change a formula that clearly works for this kind of submission. See the call for research papers.