Eventyr

Hackday Dojo

The Brighton Farm organised Hackday at the Brighthelm Centre was a wonderful chance for the coding dojo group to get together to work on something different and fun.

We reserved six places for the dojo regulars and arrived with no idea what the group would be working on for the day.  Given the project-focus of the Hackday it wasn't run as a normal dojo session, we left the Randori behind in exchange for pair-development, stand-ups and iterations.  Using the 5 minutes before we started to get an idea for the resources available we came up with the idea for generating a real-world interactive game using Inform 7 and the many different sensors that had been brought by Thom Hopper. 

Tristan (from whom I stole the photo) has described the result as a "crazy Heath Robinson unholy mashup.  A text-based adventure game was enhanced to allow real-world interaction, such as pouring hot coffee on a temperature-sensing chip, or scanning cards embedded with RFID tags.  Extremely inventive and successfully delivered on time - a testament to Scrum and the the agile programming techniques that they used."

Tom describes it as "one of the most obscure combinations of technology I've ever been involved with: a text adventure game written for the day hooked up to a web server, a temperator sensor and RFID reader. Somehow we managed to balance a plot on top of all this and got the various bits of tech (Inform 7, web server, SFTP server, Java Robot classes, RFID reader, USB temperature sensor, a load of custom Java serial code and probably some other bits I've forgotten about) working towards a more-or-less-coherent goal... all run over 3-4 hours, obviously in an Agile fashion :)"

Jez gives a very detailed account of the day.  He summarises: "The eventual demo worked a treat. Thom had adapted the temperature sensor at the last minute to be embedded in the bottom of a cut off Coke can. Hot or cold liquid could be poured into this and be in direct contact with the sensor. This would post a message to a web server which the demo laptop was polling. The java Robot API was then used to write the appropriate command into the Inform game window at the prompt."

He rather interestingly comments on the two different focuses for the game-play development: "I was focussed on producing a single simplest interaction to prove that the system would work, whereas Simon was interested in the story as a whole (i.e. start with the solution and work backwards)."  The narrative game-play vs technical implementation should have been split into separate development groups sooner, but this dynamic for is an interesting issue for iterative text-adventure game development.

For my part, although starting with helping out with the game development, I ended up finding myself pulled into the facilitator role.  I'm not sure whether this helped the group retain focus, avoid obstacles, and coordinate - but I would like to think I wasn't just loitering around as this beautiful piece of madness was developed.

My sponsored fortune cookie said: "However beautiful the strategy, you should occasionally look at the results" (Winston Churchill).  The result was crazy, but certainly did work!

Discussion:
http://www.farmhackday.com/2007/11/21/built-at-hack-day/
http://www.jroller.com/jnicho02/entry/fun_at_brighton_hack_day
http://www.tomhume.org/2007/11/brighton-digita.html
http://blog.cogapp.com/2007/11/22/hack-day-roundup/

Photos:
http://flickr.com/photos/tags/brightonhackday/

Communication: Toilet Stories

One day, toward the end of a long brainstorming meeting, we came up with the idea of putting up little one-page stories, called episodes, in bathroom stalls discussing new and interesting testing techniques. Somebody immediately called it “Testing on the Toilet,” and the idea stuck.

We formed a team of editors, encouraged authors to write lots of episodes and then bribed Nooglers with books and T-shirts to put up episodes every week. The first few episodes touched off a flurry of feedback from all corners of the campus. We received praise and flames, but mostly what we heard was that people were bored and wanted us to hurry and publish the next episode.

Eventually, the idea became part of the company culture and even a company joke, as in, “Excuse me, I need to go read about testing.” That’s when we realized that we had what we needed: a way to get our message out.

The Google Way: Give Engineers Room - New York Times.

Swearing at work

"Regular swearing at work can help boost team spirit among staff, allowing them to express better their feelings as well as develop social relationships, according to a study by researchers.  Yehuda Baruch, a professor of management at the University of East Anglia, and graduate Stuart Jenkins studied the use of profanity in the workplace and assessed its implications for managers."
Swearing at work boosts team spirit (Yahoo! News) (Via Tom).

---

From the paper 'Swearing at work and permissive leadership culture: When anti-social becomes social and incivility is acceptable' by Yehuda Baruch and Stuart Jenkins (published in Leadership & Organization Development Journal):

"Social swearing provides stress release for individuals, and helps to develop group
norms and cohesion. This subsequently improves both individual and group well
being. Conversely, annoyance swearing tends to increase stress for individuals, and
hinders positive group norms and cohesion, hampering both individuals’ and groups’
well being."

I'm very curious to look through my data for examples of these two.  I suspect I'll find some more lovely examples. 

I'm looking forward to reading this paper thoroughly, and hope I find time to follow up this reference:

"Taking this point to the extreme, Wajnryb (2003) offers advice for executives who
have to make staff redundant: “If you’re worried about which laid-off employee is
going to show up with a semi-automatic and shoot up the office, be wary of the
non-swearers”."

PhD Forum: HCI Applications (paper 2)

I popped in for one talk in the PhD Forum (HCI Applications).  Petra Isenberg (University of Calgary) was giving a paper called 'Information Visualization in Co-located Collaborative Environments', which I did not feel I could miss as I am currently very curious about collaborative information visualisation.

Her research has three main problems she is trying to address:

• We don't really know how the collaborative information analysis process works
• We don't really know what the design guidelines for digital tools of this type are
• We don't really know how such things would be used in the real world

She found 8 distinct processes used by groups to work with data and decide strategy (selection, operation, strategizing) - and I must find a paper on this.  Really interesting was the finding that there was a lack of common temporal order for these processes.  She went on to describe her work on looking at design guidelines for digital tools, and considering how a visualisation system could be generated in a real world setting to support such work.

---

Johanna Hunt
Official GHC 2007 Blogger
You may comment on this blog by visiting the GHC Forum

Coding Dojo 11

The eleventh Code Dojo (my, this is starting to look well established!) was on 26th March at the FP Offices.  We continued Kata Four (Data Munging) in Java - looking at the second part of the Kata. 

It was good to have some new people attending (PiersCawley, GrahamCarlyle and MakotoInoue) and they helped instigate a lot of interesting conversation at this session about ways to address problems, Test-Driven Development, Up-Front problem discussion (as opposed to solving), refactoring, the limitations of Java, and applications of Agile. 

I almost wish I had taken notes. 

(Thankfully the session was recorded so I can just watch the video again at another time should I choose.)

As Dom puts it: "I learned an enormous amount from the interaction this evening. [...] Chatting  afterwards made me realise how I tend to be very focussed on solving the problem at hand rather than stepping back and trying to create something beautiful."

Festival Dojo

We are almost ready to launch ticket sales for the upcoming Brighton Coding Dojo night which will be held at the Creativity Zone at Sussex on 10th May as part of the Brighton Fringe Festival.   Tickets will be £3/£2 and the night will be fully catered (a real bargain).  Public, students and professional programmers are all welcome (although some knowledge of programming constructs is preferred).

Further information will become available on http://www.brightoncodingdojo.co.uk/ within the next week or so.

My major question right now is whether I think people can learn a new language and the concepts of test driven development in one session…  Should we announce the language so that people all have the chance to level the field and then apply TDD?  Should we just emphasise the learning the language together and make it an exploratory night?

This question will impact strongly on how the coding dojo night will be organised – as we cannot guarantee skill level, language or knowledge.  So far it is proving quite difficult.

The lack of clarity of purpose has affected even our publicity:

 

I fear people may expect some kind of performance-art martial-arts display on coding…

Dojos 9 and 10

19-02-2007 - Kata 4 Data Munging in Java

Enjoyable night where everyone left satisfied that they had successfully completed the first part of Kata 4 (Data Munging).  There was even time to look at some decent refactoring.  Once again there was an entertaining tension between those that believe in test-first at all times, test sometimes, and those that just don't see it at all.

---

07-03-2007 - Kata 4 Data Munging (Wednesday Ruby Session)

The interesting thing for me this night was that I actually understood what was going on to a significant level, which almost tempts me to play with Ruby.  Otherwise the session was, as Dom says, "Exactly the same as the last time, we only completed the first part of the kata."   That doesn't mean it wasn't enjoyable.

Coding Dojo 8

Coding Dojo Eight was last night.  We somewhat resurrected the number of attendees by finally appealing to a language other than Java, which I think constituted a good thing and was a refreshing change.  Dom ably led the session, and had put a lot of work into preparing slides and a starting point for addressing the soduku solving challenge for a second time.

This time the problems with finishing the challenge seemed lay more in the depth of the challenge to be explored, although there was again a divide between people who prefer using TDD and those who are not so familiar with it.  The age where the solver class sat empty will stick in my mind for some time, and will remind me of the power of well-timed tea-breaks to help the group along (and not to forego them in future).

My dojo energy is currently split between organising the weekly sessions and the exciting plans for the Fringe Festival Coding Dojo Night which will be held at the InQbate Creativity Zone at the University of Sussex on 10th May.  More details will become available on the event website soon.  It's enough to say that I am very excited about it.

Also, I have finally changed the FP dojo wiki from friki to vqwiki - affording me the option to actually make it look nice down the road.  The data is all transferred and the wiki is ready to be used.

Studying Groups

Interesting question was raised by my class on Monday, which has occurred to me before but I have never stopped to think about:

Why study group process in software development over any group process?  Is there something different about software development, or does the literature in fact just remain true for all groups across all domains?

I'm sure that can make an interesting piece of PhD research for someone.

Coding Dojo 7

Coding Dojo Thoughts..

Session 7 (22-01-2007):
This session focussed on Sudoku Solving.  Although the group never really came close to exploring the algorithms for solving sudoku they did work hard and representing the board.  Again, this was a case where perhaps something should have been created in advance, for example an example board.  It should be interesting to see how the code they created can be continued to another session.  The new layout based on the recommendations from the previous group seemed to work well.  Now all we need is less deadly chairs...  (As ever Jez is much more reflective about the session.)

Fringe Festival:
A group of us are currently toying with the idea of running a large dojo session as part of the Brighton Fringe Festival in the exciting Cetl in Creativity space.  If the idea carries off it will be impressive.  Contact me if you are interesting in volunteering your time or support to this project.

Group Process

So today I am setting myself up for the spring term MSc course that I lead. 

The course is Interdisciplinary and Group Processes (previously Integrated Studies II) and aims to expose students to the practical difficulties involved in group interaction for software development.  As ever it has thrilling possibilities as I cannot predict how it will end up.  So much is dependant on the cohort that come in and how they work together. 

I am hoping all goes well.

Coding Dojo 6

Dojo 6 was again a quiet affair - looking at Kata 6: Anagrams.   The small-group dojo is consistently more fun and more productive, and this was generally agreed in the call I put out to the group about how we should run it in the future. 

The main things which came up this week was not interactional but organisational, which made a nice change.   I think we may be mostly settling into a rhythm for pairing.

I just need to think about this issue with layout for the next session:

(drawn by an attendee)

Dojo 5 - Return to basics

Hmm, so this week's coding dojo session was a very small one.  I'm hoping that the reduced numbers has been due to general illness and the desire to stay indoors in the warm and dry, that generally comes upon us all at this time of year, rather than anything else.

It was good to look at the binary chop kata at last.  Four implementations were managed out of five, although more were discussed.  I really wish we had had more time to actively discuss and reflect on the goals of the kata:

1. As you’re coding each algorithm, keep a note of the kinds of error you encounter. A binary search is a ripe breeding ground for "off by one" and fencepost errors. As you progress through the week, see if the frequency of these errors decreases (that is, do you learn from experience in one technique when it comes to coding with a different technique?).
2. What can you say about the relative merits of the various techniques you’ve chosen? Which is the most likely to make it in to production code? Which was the most fun to write? Which was the hardest to get working? And for all these questions, ask yourself "why?".
3. It’s fairly hard to come up with five unique approaches to a binary chop. How did you go about coming up with approaches four and five? What techniques did you use to fire those "off the wall" neurons?

It was interesting that having a pre-written test helped the group greatly to pull in the same direction, but not to produce efficient code.

I must sort out my knowledge of java for the next session - I keep feeling like this is a game I want to play rather than just watch.

Coding Dojo Revisited

So on Wednesday we held our one-off Coding Dojo session.  I was exhausted post-XPDay but thoroughly enjoyed myself.

It will probably be the last time we try to hold it on a Wednesday.

It was a slight failure in terms of attendance (dropping from 12 to 5, due to a general inability to make Wednesday sessions or confusion over date), but it ended up being great fun.

The group revised the code from the previous session.  Once again the aim was to create a text adventure game in Java, with elements specified (a tribute to 24 Hours of Inform).

This time, due to more cohesion in approach (reduced numbers led to increased turns and increased agreement, amongst other elements) the group succeeded.

It was also nice to see the spontaneous introduction of storycards by Jez (who describes the interesting features from the session much better than I can).

Dojo Game

The dojo ran again last night, and seemed to go well.  This time we started to explore representing a text adventure game.  The elements* I gave were never implemented (or even considered beyond the first 5 minutes).

I think there is starting to be an interesting tension between methodologies here.  Those that are used to development driven through TDD methods vs. those that are used to traditional methods.  Both these groups seem to be being subverted by the time constraints, as people leap in to do the one thing in the problem space that they can immediately see in their 5 minute slot, and so neither methodology leads as each individual pairing over-rules any systematicity.  The result is, simply-put, something of a mess.  Fascinating.

I am starting to think I should get people to sign ethics forms so that I can properly look at the data for how this is working.  It looks like it could produce some beautiful work.  Shame this is social and not for my PhD.

---

Interesting Thoughts from Dojo Session 1: Tom, Dom, Jez, James, Joh

Very Interesting thoughts from Dojo Session 2: Tom, Jez 

Flickr Photos: CodingDojo

---

One thing which I think we need to explore at the start of the next session is the purpose for the dojo. 

• Are people coming to explore a problem space, experiment with agile, learn from other people, show off their programming skills, etc? 
• What do people see the purpose of the dojo as: art, practice, learning, teaching, exploring, communicating, socialising?
• Should we be aiming to be 'completing' a task in the time period, or just exploring the start and space?

This should be to open up discussions that have already been happening in the tea-breaks and certainly not to change or formalise anything.  At the moment I think there is a very good balance in the various interests and desires of everyone involved.  A stated purpose would be limiting and restrictive.

---

* A House, A Cat, A Blue Necktie, A Nodding Dog Ornament, Something Orange, and a Lift.

Dojo Checkout

The first Coding Dojo session seemed to go very well.  There was a good mix of skill-levels and some interesting approaches to the problem of representing supermarket purchases in Java (Kata 1).   One thing I found interesting was the  notable difference in speed, interaction and achievement between pairs who had prior experience of working together.  I honestly had not expected it to be so marked.

(Tom's photos are here, here, here and here.  His account of the session is here.)

Next time we need:

• A better projector screen (although our makeshift piece of paper functioned well enough, it was not ideal).
• Some clearer rules of engagement
• Forfeits, etc
• Filter coffee (so I can have some, darn that allergy)
• A better way for me to keep time
• A better microphone
• Unit testing from the beginning!

Type Club

Thanks to the generous support and enthusiasm of Tom at Future Platforms, my idle desire to set up a coding dojo in Brighton has now been realised.

Further details are available on the wiki.

I am very excited by this.  The approach potentially has so many applications for teaching programming, group work and communication skills, while also being good fun. 

I'm very much looking forward to the first night.