Game of Life has started to become a little bit boring.  So we would like to try something else on our next code retreat. Is this considered heresy? :)  Has anyone of you tried another problem domain?

Any suggestions for a good problem?

What were your experiences?

Any opinions? Is it a good idea to try something else, or would you rather stick with GoL?

Tags: game of life, problem domain

Views: 734

Reply to This

Replies to This Discussion

Hello Marco,

Your question is not at all heresy. In fact, it is a fairly common question. Although this question is common,it is usually asked by first-time coderetreat attendees. Based on how you worded your post, it sounds like you are a fairly experienced coderetreater. How many coderetreats have you or others from your group attended?

What aspects of Conway's Game of Life have you become bored with? 

I've observed that sometimes frequent coderetreat attendees get "stuck" implementing Conway's the same way over and over, or they focus on the same problem areas.  At your next Coderetreat, try changing things up a bit. Instead of starting with the rules, try starting with implementing the live neighbor counting algorithm. Or try starting with the user interface. Often starting in a different place is good enough to get you thinking differently about the problem. When you think differently about the problem, you may discover something you didn't see before.

If that doesn't help, try changing up the exercises you do at Coderetreat. If "no conditionals" is getting a bit dull, try "no return values", or something more challenging. Or come up with your own new, challenging exercise.  This is a good alternative to finding a new problem because Coderetreat is more about practicing coding techniques than it is about Conway's Game of Life.

There have been other attempts in the past to use a problem different from Conway's Game of Life, but they didn't seem to work nearly as well.

Lastly, you could also change things up by trying a Legacy Coderetreat. A Legacy Coderetreat uses the same basic structure, but you spend the day attempting to improve an ugly existing codebase. Thus, you don't work with Conway's Game of Life and the exercises are very different.

I'd love to hear from others as well. Are you finding Conway's Game of Life is getting old? If so, why? Has anyone else tried a problem different from Conway's Game of Life? Is it really Conway's Game of Life that is getting old, or is it the exercises?

Jim++

Hello Jim,

thanks for your prompt response.

Although this question is common,it is usually asked by first-time coderetreat attendees. Based on how you worded your post, it sounds like you are a fairly experienced coderetreater. How many coderetreats have you or others from your group attended?

I attended 4 and facilitated one. I wouldn't call myself very experienced, but I think I have already seen a lot of different approaches: Connected-Cells, Various Board implementations, heavily stubbed/mocked approaches, Inside-Out, Outside-In, various kinds of rule implementations - with and without conditionals, logic on the board, on the cell, in a rule class etc.

What aspects of Conway's Game of Life have you become bored with? 

No particular aspect. I just would like get my teeth into some new problems. GoL has two interesting problems: the rules and the neighbor detection. But there are a lot of very different problems out there.

I've observed that sometimes frequent coderetreat attendees get "stuck" implementing Conway's the same way over and over, or they focus on the same problem areas.  At your next Coderetreat, try changing things up a bit. Instead of starting with the rules, try starting with implementing the live neighbor counting algorithm. Or try starting with the user interface.

That's interesting! I never tried to build a GUI on a retreat. I always thought that GUIs are out of scope, mainly because of their non-programming issues.

If that doesn't help, try changing up the exercises you do at Coderetreat. If "no conditionals" is getting a bit dull, try "no return values", or something more challenging. Or come up with your own new, challenging exercise. 

Yes, we plan to do Object Calisthenics on our next retreat - thanks to Martin Klose. I just wonder if that is enough to get it interesting.

There have been other attempts in the past to use a problem different from Conway's Game of Life, but they didn't seem to work nearly as well.

That's very interesting too. What have you tried? And why didn't it work well?

I already attended a "mini-code retreat" consisting of only two sessions, that used tic tac toe as the problem. I worked quite well, although it is smaller in scope than GOL. We currently wonder if it would make sense to use for our next retreat.

Thanks for your answer Jim, it already provided some food for thought.

Marco

Marco Emrich said:

I wouldn't call myself very experienced, but I think I have already seen a lot of different approaches

There are probably an infinite number of approaches to solving Conway's Game of Life. This is one reason why we continue to use GoL.  It is not uncommon to discover a never-before-seen approach at a coderetreat.

That's interesting! I never tried to build a GUI on a retreat. I always thought that GUIs are out of scope, mainly because of their non-programming issues.

I agree that GUI's may not be the best choice for a Coderetreat because they do involve a lot of distractions. That said, GoL doesn't need a very complicated UI. Many languages provide very simple GUI toolkits which are more than sufficient for coderetreat and GoL. I've seen pairs also produce very nice text-based UIs or very basic HTML-based UIs.

The point is try something different. How does starting from the perspective of the UI change you're approach to implementing GoL? Does it affect how you implement the other aspects of GoL (the rules and the neighbor counting)?

Yes, we plan to do Object Calisthenics on our next retreat - thanks to Martin Klose. I just wonder if that is enough to get it interesting.

It often is enough! Remember: the goal of a coderetreat is not to implement GoL. Instead, it is to practice coding techniques we normally don't get a chance to practice. It's about becoming a better developer.  If you take this perspective, then GoL fades into the background somewhat and the exercises become the interesting part.  This is another reason why we've stuck with GoL.

There have been other attempts in the past to use a problem different from Conway's Game of Life, but they didn't seem to work nearly as well.

That's very interesting too. What have you tried? And why didn't it work well?

The most common "alternative" is Tick-tack-toe (also known as Noughts and Crosses or X's and O's). However, if you think GoL gets old, consider what it is like to use a game everyone has played a thousand times. In my opinion, GoL is much more interesting that Tick-tack-toe.

Some groups have also tried Uncle Bob's Bowling Game Kata, but it turns out implementing a bowling scoring system too hard of a problem to tackle at Coderetreat. If a problem is too hard (like this one), then most of the day is spent grappling with the problem itself and becomes a major distraction to the other, more important aspects of coderetreat.

Jim++

Hi,

We tried out some other katas at GDCR as well as Game of Life, and had very positive feedback on this aspect. I wrote it up in a blog post:

http://emilybache.blogspot.se/2012/12/global-day-of-code-retreat-20...


HTH

Emily

This is probably the best, most compelling application of alternatives to Game Of Life that I've seen thus far.

I like how you gave participants a choice of several different katas. Choice is very often a powerful motivator. I also like how you picked the four specific katas with very specific learning goals in mind. This is exactly how we encourage facilitators to pick exercises.

Your experiment highlighted that the problem itself isn't the focus of the day, but you also showed that using a different kata can help direct learning (similar to how choosing different constraints and exercices directs learning).

The primary argument against using different katas is that participants will waste time learning the new problem instead of practicing specific aspects of writing code. In other words, switching katas can be distracting. What did you observe on Saturday? Did people pick one kata and stick with it all day long, or did they switch katas every session?  If they switched katas, approximately how much time did people spend learning the new kata rather than doing the given exercise?  Did the katas at any point distract from other learning or did they always help and encourage learning?

Conway's Game of Life has been battle tested for almost four years now. GoL will always be a good choice for coderetreat, and it may continue to be the default choice for the foreseeable future. However, you've shown that other problems can also work. I think this is worth exploring further.

Jim++

Emily Bache said:

Hi,

We tried out some other katas at GDCR as well as Game of Life, and had very positive feedback on this aspect. I wrote it up in a blog post:

http://emilybache.blogspot.se/2012/12/global-day-of-code-retreat-20...


HTH

Emily

I agree Game of Life is a good kata, with lots of challenges to it. I agree that by repeating the same kata, you quickly learn a way to solve it, so solving it no longer becomes the focus, and you can learn more about deisgn, try out different approaches and constraints etc.

All the other katas I suggested are quite easy to get in to, since they provide starting code and/or an obvious line of enquiry - "implement tests for this class" (Tyre Pressure, Gilded Rose), or "refactor this" (Tennis) or "write this test first, then this test" (String Calculator). So none of them are as open ended as Game of Life.

What I observed was that pairs didn't pick one of the other katas to work on all day. They did String Calculator for two sessions to get comfortable with TDD, then moved to Game of Life. Or they did Game of life for three sessions, then tried String Calculator for two, in Clojure. People who did Gilded Rose did it for two or three sessions, then tried Tennis and Tyre Pressure.

For a beginner to TDD, they need concrete instructions and clear boundaries, so these katas are quite easy to get started with. For experts, they can probably solve these katas completely in 45 minutes, after only one or two sessions of trying, which gives a sense of achievement. Then if you do them again, you can try out some other approaches. I'm not sure you'd want to do the same one for 5 sessions in a row, these katas have a smaller scope than Game of Life. You would repeat it that much if you wanted to perfect it for a prepared kata demonstration, but that's not usually a goal at code retreat. It might be at a coding dojo.


There is definitely a value in knowing a kata well enough that solving the problem is not the focus, but experimenting with tests and designs becomes possible. Some katas are smaller and easier to learn than others. I've also experienced groups struggle with Bowling Game in a coding dojo, and I found if I give them a list of test cases to implement up front, it works better.

I think TDD has four main subskills - designing test cases, refactoring, driving development incrementally with tests, and designing clean, testable code. Game of Life is a good kata for practicing all these skills together. These other katas are basically only challenging you at one of the subskills and lets you focus on improving at just that aspect.

So to answer your question, no, people didn't seem to get hung up on understanding these problems and wasting half their time on that. They were quickly up and coding and learning, as far as I can see. That's also been my experience when I've used them in coding dojos.

Emily

Instead of trying to implement something other than Game of Life, how about trying implement Game of Life in a different language? Switching from something in the C/Java family of languages to something in the lisp family, for example, would be an interesting challenge. I'm curious to see what a prolog version would look like, myself.

I believe that using other programming languages is already an accepted practice at code retreat. We had Ruby, Python, C++, Java, javascript and Clojure at various times through the day. This does add variety, but if neither person in the pair knows the language, progress is pretty slow and there is much googling after syntax.

Emily

... and like Jim said in the facilitator video: learning a new language in a code retreat can be fun, but you shouldn't do it all the time. Otherwise you would miss a lot of other learnings that the constraints can provide.

To come back to the original discussion: After facilitating two more code retreats (including the Nuremberg GDCR12) and also trying several katas with students at my work place (www.webmasters.de) I came to the following 'conclusion'.  (Maybe 'conclusion' isn't the right word, since my experience is still very limited.)

I think code retreats and dojo's both have their place. While they have some general goals in common (becoming a better coder), they provide quite different learning experiences.

Small Katas done in Dojo or Randori-Style (like Emily describes in her Book - which is really great, by the way) are best for introduction or skill improvement in specific areas. E.g. the StringCalculator-Kata is very good for learning basic tdd. I also found tic-tac-toe quite useful for practicing Object Calisthenics.

Code Retreats, on the other hand, are much more open. Its not predetermined, what kind of learning experience you will get out of it. Constraints might force you to learn new things. You might try a new language or you will just pick some new cool techniques (sometimes very uncommon ones) from your pair - which can be anything from command line tricks to simple keyboard strokes to specific tdd techniques to social skills to complex architectural insights.

After the last experiences, I'm somewhat convinced that for a classical code retreat it's best to stick with GOL in order to enable the "problem fades to the backround"-effect. While for seeking out targeted learnings, like tdd-introduction or Object Calisthenics or SOLID-principles, ... it seems to be very useful to have a specifically tailored problem, that provides exactly the learning experience, you are seeking out. 

I did reverse polish notation calculator and SIP server. I will post slides here in free time.

Reply to Discussion

RSS

© 2014   Created by corey haines.

Badges  |  Report an Issue  |  Terms of Service