Software Craftsmanship: The Art of the Performance

Growing up I was a music geek. My social life really was music. It’s surprising really that I grew up to be the balanced individual you see today!

Early years of the descant recorder primed me for over a decade of my younger years being devoted to piano lessons and clarinet concerts. At the peak of my after-school antics, I was making weekly visits to 2 clarinet tutors (one for performance style and one for technique), a piano tutor, and a musical theory tutor, as well as participating in weekly music groups, monthly orchestra rehearsals, local competitions and frequent winter and summer concerts. I can’t even begin to imagine how much my parents spent (in terms of money, time and fuel costs) to ferry me around to all these things.

Of all of these activities, the single most searing memory of my musical life was the daily ritual of an hour of practicing musical scales, arpeggios and study pieces … all that before I even opened a piece of music to play, and even then a further hour could still be spent perfecting just a couple of bars. I’ll not lie, in addition to regular ailments like pinkie finger sprains and split lips, my dad still can’t bear to listen to me abusing Gershwin piano pieces.

The funny thing is, out of all of that weekly torture (for both me and my parents!), I have lifelong friends and I can still perform a killer Adagio movement from the Mozart Clarinet Concerto.

But how is this important to a software developer?

My musical scale is your code kata

Almost every piece of music draws on a systematic, yet unique, combination of musical basics – scales and arpeggios. Practicing these basics until you barely have to think about where to put your fingers or which keys, strings or valves to use will give you the benefit of muscle memory. A musical scale on its own is not something you’d see being performed at the Young Musician of the Year, but the act of the rehearsal prepares you for the performance.

The concept of a kata has its origins in martial arts, the system of performing a set of movements or body positions as an exercise.

A kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer.

Code katas allow you to take a small programming problem and practice keystrokes while developing muscle memory and improving your technique. The process of “performing” a code kata is not to arrive at a solution, close your laptop and move onto something else. The benefit lies in the practice – coming up with different ways to solve the same programming problem, and getting feedback on how others would solve the problem to reinvest into your solution. The community of followers of this concept means that there is always someone on hand to take a look at your “answer” and provide a critique in the form of feedback or comments. If you feel happier showing it to someone you know already then even better – encourage your co-workers, colleagues or friends to take it up too!

My music group is your coding dojo

Once a week I would meet with my friends Charlotte and Debbie for a speedy lunch before heading off to 45 minutes of rehearsal time with our music group. Watched over by our conductor, (the venerable Mrs Marijke Harris, an insanely scary woman … of course this is not a requirement for your coding dojo!) we would be given a piece of music that we would play as a group and then take away, each to practice our respective parts, and return with the following week in the hope of having improved after a week of practice.

Like our weekly music group, a coding dojo meets at a predefined time and place and the organiser delivers the equivalent of a piece of music – a programming challenge. The arrangement includes one computer attached to a screen with each one of the group taking it in turns to act as keyboard pilot. With the support and input of a co-pilot and a small team, each pilot takes his turn to add to the code and explain what he is doing to solve the problem as he codes.

If I want to learn Judo, I will enrol at the nearest dojo, and show up for one hour every week for the next two years, at the end of which I may opt for a more assiduous course of study to progress in the art. Years of further training might be rewarded with a black belt, which is merely the sign of ascent to a different stage of learning. No master ever stops learning. If I want to learn object programming… my employer will pack me off to a three-day Java course picked from this year's issue of a big training firm's catalogue. Nuts to that – acquiring coding skills is not an instant gratification process.

A coding dojo lasts for a predefined amount of time. Once that time is up the session is over, whether the solution is solved/completed or not. The purpose of the exercise being not to rush to solve the problem set, but to try to jointly create the best solution as a team. If my friend Debbie were to play her part in our music group exceptionally well and not let the rest of the group keep up, we would not learn a great deal during our 45 minute rehearsal. However, if we were to practice as a group, taking the time to listen to one another and understand how the music is developing as we improve, we have a much greater appreciation for how the piece should sound in its entirety – a much better experience for the listeners, just as the route the solution of your programming problem could mean a much better experience for your users.

My orchestra rehearsal is your code retreat

I loved travelling to orchestra practice every month (except one month - Debbie, Charlotte, vodka and a very late night were involved). The monthly bus trip meant I’d see friends from all over our county and from different schools, and get the chance to catch up on all the latest goings on. I participated in the orchestra for 4 years, starting off playing the “support” music for the clarinet section (for those orchestra folk out there I was 4th chair clarinet, and we know what that means – 4 pages worth of full bars of rests punctuated by the odd semibreve, quite tricky if you lose count part way through!). Being able to learn from those around me gave me the chance to improve based on suggestions of technique or style from others in my section. In my final year, I graduated to 1st chair … meaning I was finally playing the tune!

In the same way that my orchestra practice gave me the chance to inherit techniques from fellow performers, so the notion of the code retreat can offer programmers the chance to “rehearse” with their peers.

Code retreats are a concept designed and implemented by Corey Haines. They have been held around the world as part of an initiative to get developers to focus on the fundamentals of software development.

A code retreat is a full day of intensive coding practice, focussing on fundamental skills involved in software development and design, usually the four rules of simple design. The purpose of the day is to focus on getting things right rather than getting thing done, a somewhat alien approach given the pressures of a programmers day job being “get this done and move onto the next bit”.

Code retreats take the cellular automaton devised by John Horton Conway, otherwise known as Conway’s Game of Life, and through a series of 45 minute session intervals, encourages pairs of programmers to break old “getting it finished” habits and focus more closely on the manner and techniques that they are using to try and solve the problem. After each 45 minute session all code is deleted – not moved, saved or put in a branch, just deleted. The problem behind Conway’s Game of Life would be very difficult to “solve” in just 45 minutes, which is entirely the point of a code retreat – asking participants to solve a problem in an almost unachievable environment.

Code retreats help to dispense with the pressure of having to complete a problem and skipping over the process of learning anything from your solution, and focus more closely on doing things “right”, developing techniques and reinvesting critiques of your “solution” back into your repertoire.

Minimise the distance between “getting it done” and “doing it right”

Anyone who considers themself highly proficient in an area will know that without practice, training and developing technique your grasp of that area is purely superficial. Giving a budding pianist a Rachmaninoff piano concerto and asking them to perform it to their friends without practice would be like trying to hold water in a sieve, practically impossible.

By taking the time to develop and improve yourself, your technique, and your understanding of fundamental elements of your craft, you create an almost unforgettable platform on which you can build and expand your expertise, and in addition always have behind you to fall back on.

Playing the clarinet these days makes me frustrated – frustrated that my tone lacks clarity, my fingering is clumsy and slow, my breathing is not musical – I’m frustrated that I can’t play as well as I used to. But I know that a few weeks of practicing my technique will improve my tone, loosen up my fingers and encourage better breathing.

You can start your path to technical greatness by checking out the 21 katas on Dave Thomas’ blog. You can look out for a a coding dojo in your area, or maybe even participate in one of Jon Jagger’s CyberDojos at an event near you. You could even set up your own code retreat as part of Corey Haines Global Day of Code Retreat (see the final paragraph here). Contact Corey through his site for more information on how you can participate.

Go on, you can say it. You thought that my musical background couldn’t offer an insight into your programming world. I am full of surprises .

Rachel Hawley (DevExpress)

1 comment(s)

Rachel Hawley (DevExpress)

Corey Haines inspired this piece. I watched his session at NDC 2011 and he helped me to tie his experiences to my own so that I could better understand in order to pen this.