Here is the wrap-up I wrote yesterday evening on the Software Craftsmanship conference in London while waiting for my plane to get me back home. I would like to thank Jason Gorman for organizing this conference. It was overwhelming and one of my favorite experiences so far. I also have to thank Gojko for his Specification Workshops talk. I’ll try them out. Micah Martin additionally made me aware that I need to practice with his Kata & Sparring session. You should read on the rest of the conference in the extended body.

Introduction

Jason Gorman invited to the first conference on Software Craftsmanship. Some weeks before the conference took place there was some ongoing discussion on the Software Craftsmanship google group on the definition of Software Craftsmanship and the distinction towards the Agile movement. Being a practical conference there were a lot of sessions focused on practices shown for the intended audience: Software Craftsmen.

Courses visited

Here are some brief insights based on my notes that I took during participating particular sessions. Before going into much detail on each session I will describe in brief what the session was all about before denoting my particular insights.

Mapping Personal Practices

Adewale Oshineye from Google presented very briefly two diagrams he created during similar workshops in the past and showed the audience two styles, that could be used. The goal was to build a mindmap structure of particular practices that were regularly applied from each of the participants. After that everyone had 10 minutes to write down her particular practices. After that an introduction round was started, where every participant should describe the contents of their mindmap to the remaining people in 90 seconds.

This technique was quite overwhelming. One question during the starting phase arose on how to focus the context of the map. Adewale had included technical and personal practices into his maps, so that this question was reasonable. The clue behind this technique is, that you can define the context and the focus as you may see fit. You can decide to just focus on technical practices or just on collaboration practices. Right before attending this session I already thought on trying to use this technique to see evolution points for the workers in my group and use it as a visual tool as well.
During the presentation of each participants’ map, I made some notes about what practices I apply but forgot to include in my map, what other practices sounded interesting and on what I would like to try out next. The list of interesting practices included E-Mails to oneself as a todo list, rather than wrapping up third-party frameworks build a more simpler solution on your own and using post-it notices to make the step from the short-term memory towards the long-term. One participant described that he first of all comes up with a name for a function and then deciding based on the name, on which class this new method should belong, as a design aid. Another participant described, that she likes to get some distance from the topic when striving with a hard problem. Getting some time to think over it can lead to a better solution in the end. Another one described that he regularly uses the revision history to get a clue of what happened to a particular class. There was also a call for help seekers, that do not argue their seek directly but rather indirectly instead. The one bringing up this item described that he had noticed that pattern and made himself aware of this. Traceability was also mentioned in that round. One participant described, that he regularly is asking stupid questions to resolve thinking abilities on his collaborators. The last thing I denoted on my list of interesting things is the ability of one participant’s customer to actually read the source code. While being able to have customers participate full-time on the project, this can lead to more direct customer conversation, if technical staff and customers are talking the same ubiquitous language.

Ruby Kata & Sparring

Micah Martin from 8th Light introduced the parallels between Martial Arts and Software development. He described, that during learning and practicing martial arts he was doing the same stuff over and over again; sometimes also for the sake to get better moving abilities during the fight by practicing movements that are actually not used in the fight itself. Micah concluded that the combination of practice, experiment and reflection leads to mastery in software development as well. After making his mission clear, he showed the audience an actual Kata he practiced over and over again. He showed the Langston’s Ant implemented in Ruby live.

Roughly in 10 minutes Micah used test-driven development to come up with a useable class, that could also be shown in a prepared evaluation program over several steps. After the session I got the opportunity to talk to Micah on his presentation. He stated that he had practiced solving the problem 30-40 times before. Since the solution just takes about 10 minutes to implement, he was also able to incorporate those sessions during daily work. The solution seemed very quick to me, even though not rushed. He ended up with roughly 20-30 lines of code and as much of unit test code as well. Since I saw his Kata I’m also planning to practice more small Katas in the next few weeks. Also I am thinking over to show some of these during a coding dojo session as a prepared Kata.

Specification Workshops

Gojko Adzic from Neuri gave a great talk on Specification Workshops, a technique he introduces in his latest book “Bridging the Communication Gap”. He introduced the session with an e-mail from an angry customer, where the customer described some business conditions with obvious inconsistencies. He then described the technique as a heading activation in each iteration right after picking the stories to implement in the next two to four weeks. Bringing together business people, developers and testers, discuss new stories in examples builds a shared understanding of the business among the relevant people in the project and helps building a common ubiquitous language.

Initially it seemed that there were just two people attending this session. Gojko nearly suggested to visit one of the sessions that were taking in parallel. Then a crowd of nearly 30 people came in, filling the room completely. There even were not enough charis for everyone to sit in there. During the talk I realized several concepts I just recently also read in other books. Gojko included in his reasoning the need to focus on the what and why during these sessions. The Poppendiecks describe this fact as set-based discussion rather than focusing on point-based negotiations. Developers and testers need to focus on what to implement rather than how and business people should be asked on the why’s behind proposed solutions in order to get an understanding of the underlying business problem and being able to cope with that. He introduced a story on printing from Java in the early days, which had troubled one of the projects he was on. After asking the customer why there had to be printing support in the software – which was rather complicated by that time – the team found out, that a re-arrangement of the UI navigation would make the need for printing support obsolete – and besides that more user friendly as well. The customer just kept asking for this since the company that had build the previous system was not able to re-arrange the UI flow. After the talk I had some words with Gojko. I am very pleased that he gave me a copy of his book “Bridging the Communication Gap” and I directly had to ask him to sign it for me. After reading the review comments from Lisa Crispin on it, I had already put it onto my order list on Amazon – now I can drop it from that list.

Gojko already put up the resources on his course on his blog. The slides should give you a good start on the topic.

Responsibility-driven Design with Mock Objects

Willem van den Ende and Marc Every from Quality Without A Name lead this session. Roughly they introduced the idea to use mock objects together with CRC card design in order to be able to directly incorporate the results from CRC design sessions into the software and unit-tests. In a rotational pairing session they also showed how to implement these for a text adventure game using rubyspec while including people from the audience.

Willem and Marc gave some guides before kicking off the demo session. On of the main goals with responsibility design is to avoid train wrecks, where a client of a class needs to call a function on one class getting another class, calling a function on that one, and so on, until the actual work happens. This distracts the reader of the source code and leads to high maintenance costs of software. One of the participants was obviously very familiar with responsibility-drive design since he gave several hints and remarked a lack of previous thinking during the live demo. The concept overall seemed to be very interesting, though the technique seems to be harder to learn.

Empirical Experiences of Refactoring in Open Source

Steve Counell from the Brunel University showed his empirical results from 7 open source software projects. He examined 15 refactorings for occurrence on these projects and had some very insightful graphs showing the usage and correlations to other refactorings and code-smells for the developers. Among the conclusions he gave were the tendency towards simpler refactorings, avoidance of encapsulation for the sake of testing purposes and interrelationships between i.e. move field and move method.

His graphs also showed that during the first few revisions of a class there were much more refactorings applied than to a later state. The conclusions from the code smells examination showed, that seemly easy code smells usually lead to a chain of up to 200 refactorings. Among these costly code smells were duplicate code and large class or large method. He closed with the tendency to not give in to seemingly easy smell removals, since they can very obviously pile up. In the discussion afterwards it was stated that there might be weight in the value coming from the costly smell removals as well. The overall study seemed very interesting to me. Maybe someone also comes up with a combination of version control, bug tracking and refactoring and examines their interrelationships. Steve also stated that the software they used for measuring the refactorings can be made available to other companies as well.

5 Reasons to have a Coding Dojo at your company

Ivan Sanchez lead this session. It was a quick introduction to Coding Dojos with some easy to follow-up rules. After that he asked for volunteers to a pairing session rotating each 5 minutes for a minesweeper implementation. Due to time-pressure he had already give it a head-start with some implementation to focus the overall on the experience rather than on 20 minute initial design decision. Ivan also enforced rules for the audience to just participate when there are green tests during the tdd-pairing session etc.

The session was very impressive and as a side effect I could get insights from the 20 favorite keyboard shortcuts session that I could not participate since it took place in parallel to Gojko’s session on Specification Workshops. (Alt-Shift-Up/Down is an impressive shortcut in eclipse – I’ll have to memorize this one.) During the last three weeks I already started some Coding Dojo sessions at work. What I got to know during this session was that I need to ensure the rules behind it more and force less discussion and more implementation after an initial discussion of 20 minutes.

Conclusion

During the next few months I will deepen Coding Dojos with my team and our developers. Among the practices that were new to me and I will definitely try out for some time are Specification Workshops and the Personal Practice Maps. Specification Workshops seemed to be a great opportunity since I realized just this week at work that there was some misunderstanding among some developers and the stakeholder of some functionality where these Specification Workshops would have helped. The Personal Practice Maps I will incorporate in April when I will have a evolution meeting with one my junior workers in order to get a better shared understanding of his particular personal practices and get him towards being journeyman. The Ruby Kata session made me excited on exercising TDD more in my leisure time. The session on responsibility-design made me curious about CRC card design. I think I will get a book on this as well. All together it was a great conference and 95% of the attendees raised the hand when Jason asked for visitors to the Software Craftsmanship Conference 2010. I’m looking forward to it, too.