Is your Agile organization stuck in second gear, hampered by low velocity, messy code and technical debt? Perhaps you should start a coding dojo and work on improving your coding skills?
Imagine a band that never rehearses, only performs concerts. Its members get more used to do what they do every day — but do they ever learn anything new? Obviously, they need to get together every now and then to practice and scrutinize the details of the music in order to progress as performing artists.
The same could be said about professional programmers. How can they ever improve their skills and get rid of bad habits if they don’t have a safe environment where they can experiment – experiment with their code, try out different languages and techniques, discuss with colleagues and have fun.
Any group of developers can have fun and learn stuff by meeting and hacking something together, and if you’re thinking of holding that kind of get-together, you could try the “Coding Dojo” format. Emily Bache has just written a book, “The Coding Dojo Handbook – a practical guide to creating a space where good programmers can become great programmers”. The book was finished in May and has attracted a lot of positive attention since.
Hi Emily! How do you think the ideas and the practices of XP are doing in Sweden today?
eXtreme Programming attracted me precisely because it has very concrete advice for coders – things like writing tests, refactoring, pairing, and simple design. I worked on a project in 2000 where I think we used 9 of the 12 practices of XP, and it was the technical ones that really made sense to me and worked well. Since then the rest of the industry has also discovered Agile, but it’s mainly the team collaboration techniques that are in XP and of course Scrum that have caught on widely. The parts of XP that require a coder to change the way they work are not nearly as widespread. I didn’t expect that.
Why are they still important, in a time when Agile and Scrum are much “sexier”?
James Shore and Diana Larsen have come up with a model of ‘Agile Fluency’ (see martinfowler. com) based on their observations of many teams and organizations. It matches my observations too, and I think it’s useful. They talk about “one star agile” which is basically unadorned Scrum, or the XP team collaboration practices without the technical ones. This is where they put nearly half of agile teams today. The trouble with one star agile is that although you can deliver business value, and measure progress in those terms, you can’t consistently deliver at will. The ability to continue to deliver new versions iteration after iteration requires ‘two star agile’, and for that you need all the XP technical practices. You have to invest in automated tests, refactoring, simple design, and spreading knowledge around the team via pairing or similar. James & Diana report that only perhaps a third of teams are doing ‘two star’ agile.
Which problems are we facing if we can’t understand that there is still an important role to play for XP?
The problem with ‘one star’ agile is that you can’t reliably deliver new software when the customer wants it, in the long term. In an agile world where you deliver a new version of the software every iteration, without any big ‘design’ phase, means it’s easy for the design and architecture to degrade. People hack together new features, without paying attention to the big picture. After a while, the team will complain about ‘technical debt’, and the bug count will start rising. Developers find it harder and harder to introduce new features without breaking existing ones. Without good automated tests, skilled developers and a mandate to write clean code, your codebase can really get out of hand. You become unable to deliver new functionality in any reasonable timeframe.
So, how can coding dojos help to improve this situation?
Coding Dojos are an opportunity for programmers to take some time out from the complexities and stress of the production
system, and just work on improving their skills. If you bring all the coders from your team into the Dojo, you can not only practice writing some really good code together, but you can have valuable discussions about what your team thinks is important when it comes to things like simple design and refactoring. You can learn a complex skill like Test Driven Development, that is usually difficult to practice in your average production codebase. When you step out of the Dojo, back into your production code, hopefully you’ll feel more motivated and equipped to write tests, clean your code, and collaborate together effectively.
Coding Dojo 1-2-3
Coding Dojo in some simple steps
“Throw in a suitably puzzling Code Kata (exercise) and a safe environment to discuss topics like design, testing, refactoring, choice of code editor, tools … and you’re away! You’ll hardly be able to stop them talking and writing code and learning from one another!
Programmers generally love the plain activity of writing code, away from managers and deadlines and production bugs. When they’ve got over their shyness, most are delighted to show others how well they can actually write code, as well as to pick up tips and advice from them.
I think there are a few aspects which distinguish a Coding Dojo from are available to come to the Dojo. Perhaps more importantly, you also need a random meeting where a bunch of coders get together and hack on something, though. I think you’ll learn more if you add just a little structure:
- Hold an introduction and retrospective.
- Write tests as well as code.
- Show your working.
- Have moderation or facilitation.
On a practical level, you need a suitable room with a projector, enough laptops for everyone to pair program, and a couple of hours, perhaps every week or every iteration, when coders some people who are willing to facilitate or moderate the meetings. Those people may have to do a bit of preparation before each meeting, identify a good Code Kata to work on together, read up on the coding techniques the group will be practicing and learning about. During the meeting the facilitator will probably not write much code themselves, their role is to keep the group discussion on track, ask questions, and offer feedback. You can rotate this role among group members, or find the person with the most enthusiasm and drive, and ask them to do it.
