Summary of Software Craftsmanship 2010
The idea of software professionals as craftsmen has been around for a while perhaps starting with the pragmatic programmers entrance at the scene. Before that engineering had been the predominant way of looking at software development efforts. The book with the concept as its title appeared in 2001 and a number of thought leaders in our field has modelled themselves since as software craftsmen. It is a concept that certainly is appealing. But isn't is just another buzz that will go around for a while? Not sure but to found out more I reacted positively to Peter Linds tweet about going to Software Craftsmanship 2010 - a conference promising to miss out on keynotes and fluff in favour of joint coding and peer-to-peer learning.
The conference is 10 sessions in 3 tracks. All sessions must involve elements of audience coding. As a result the number of slides were low and the total minutes of one-way communication put to a minimum. I first went to conference organizer Jason Gormans session on refuctoring. I had already watched his - or rather imaginary enterprisy consultant Keith Bank-Account (actually a fellow of the Institute of Mortgage-driven Software Development) - videos (see below) so I had a fair idea of the concept - take something extraordinarily simple like a "Hello world" program and mess it up thourougly. This was ironically put forward as a great idea to make a customer dependent. It was a truly fun session to get as much dirt as possible into a simple piece of code. Halfway through Jason made us change pairs and introduced a new "requirement" - we were now supposed to make the program say "Hello Fredrik" instead of "Hello world". This made it painfully clear that it takes only about 20 minutes to mess up a piece of code so thouroughly that it is a real pain to maintain.
Anyways - back at the hotel I made a little implementation that is more nerdy fun than messed:
public class WorldGreeter { public String sayHello() { return createGreeting(FormalityLevel.CASUAL) + new VoidGenerator().generateVoid() + WorldGreeter.allTheStuff(); } private static String allTheStuff() { return "world"; } private String createGreeting(FormalityLevel levelOfFormality) { return levelOfFormality == FormalityLevel.CASUAL ? "Hello" : "God day"; } public static String VOID = " "; class VoidGenerator { public String generateVoid(){ return VOID; } } enum FormalityLevel{ CASUAL, HIGH_COURT; } }
In all the jollyfullness of this session lays a shared sadness - we have all seen code similar to the one we mockingly produced being written by collegues of ours and often with the best of intentions. Going to a conference like this might make me a somewhat better coder but it doesn't change the fact that the majority of coders produce code that is a mess and that they don't understand themselves. It's a kind of magic really.
The second session was by Chris Parsons
The third session was a short one where Neill Pearman
Then finally it was time to build some robots. In this case robots that can play tic-tac-toe. Matt Wynne had built a nice web site with abilitied for uploading and running competition between all entered robots. A robot is defined as a program called move that were to be packaged with its dependencies in a zip file for upload to the server. The tournament engine calls move with the current state of the board and expects a move back. In the tic-tac-toe case the state was represented as a nine character string and the move as the number of the square representing the move. I trioed up with two unknown persons where one were a C# programmer. I decided to go for Ruby and my mates were happy with that. We had a great time writing a brute force program that had a rather decent strategic approach to the game and we finally finished 7th in the overall standings for the 5 tournaments that got run. It is a bit interesting that a game with no distinct winner if both parties plays at their best can pose a problem for programmers. And indeed most lost parties seemed to be due to failing programs rather than failing strategies. Did we test drive this? No. One of my team mates wanted to but I talked him out of it arguing that a half hour program can be tested manually at a low cost.
Overall it was a great conference. A bit short perhaps but with this kind of activity you don't have energy for a longer day. If it is about the get longer I would suggest doing it over several days. And as fellow swede Johannes Carlén insightfully stated in his report from the event:
One thing though, there are a lot of people travelling around conferences worldwide advocating the software craftsmanship way of being. Where were they this sunny day of hands-on sessions in Bletchley Park?
Maybe the only hands-on they know about is keynote?
The venue - Bletchley Park is brilliant for several reasons. It is the cradle of computing and now serves as a museum. It is also a beautiful site with the mansion that may be an architectural monstrosity but nevertheless with its own beauty - the kind that comes with age. The conference administrators ran the thing smoothly and created a nice experience for us all - lots of thanks to Jason and his crew. I will seriously consider returning next year if it fits with my plans. (And possibly also contribute with a session.)
This was also an opportunity to stay another day and wander the streets of London - never a bad thing. I was fortunate to visit the same day as norwegian goth metals Tristania - great concert at the Underworld!
Old comments