CodingDojo 2

I attending the Brighton Coders (Coding?) Dojo for the second time last night. This week we were attempting to write a text adventure game in Java. The game was to include a number of things like 'a cat', 'a lift (elevator)', and some other things I can't remember as the spec hasn't been updated on the wiki yet. People were less nervous (of looking stupid!) and we nearly managed to create a working piece of software. The meeting threw up a number of areas of thought for me:

Why are we here?

There is no defined purpose to the Dojo and after a discussion it's not that we weren't told, it's just that there doesn't seem to be one. I like the freedom in that. It's an opportunity to just play and consider the results afterward… if you want to.

Working software or quality software?

What is more important, 'do it right' or 'build something that works'? For example, if you make attributes public then you can access them directly. This is widely regarded as poor practice as it doesn't give encapsulation and the opportunity to change the internal workings of a class later without affecting the calling classes, however it takes time to do things properly and maybe stops you from getting a complete working program by the deadline.

I think that I would like to do the quickest way first, get a unit test working, then refactor the class to 'do it right'.

First approach

Last week the first pair just discussed the problem and suggested a few objects. This week the first pair dived straight into creating classes. I know that it sounds wrong, but I preferred this week's approach as it was easy enough to think in classes.


We discussed whether you should prepare something beforehand. If you did then you might impose your own thoughts too much on the solution. However, this means that you aren't building on top of the experience of people not in the dojo session. It's funny not using the CodingByGoogle pattern!

I think one of the purposes of the dojo is to learn how to create something quickly in collaboration with others.

You don't have to know Java

Dave said, "sounds interesting but i think i would spend most of my time working out the language syntax rather than solving the problem, sounds like everyone who goes knows their java onions!" but it's not true. Half of the Dojo aren't Java experts and it had no effect on their interaction. Another 'purpose' of the Dojo is that you get to learn Java/analysis/collaboration by doing stuff rather than being told how to.

Refer back to the spec

After Daniel and I got part of the system to work we were unsure of what to do next. I think that we were both hoping that the 5 minutes would be up at that point and we'd be able to change places. So, we started doing the first new feature we could think of. Even though the (admittedly rough) spec was on the desk next to the keyboard I didn't see anyone refer back to it and make sure that their efforts were focussed on achieving what it asked for. Everyone was so busy trying to work with the software produced so far that the spec was all but forgotten.

Meeting people

It's great to meet people from the industry who have a similar outlook. Many of us stay hidden in offices around town and never cross paths. I'll be inviting people to connect up with me on LinkedIn and continue to be more sociable!

events hacking
It's All In The Game blog (c) 2005-16 by Jez Nicholson