|"I know Kung Fu!" - "Show me."|
On Monday we had yet another successful Code Dojo (see here), but what is a Code Dojo and why would we want to participate in one? Let us understand the context.
We live in a world of fly-by-wire businesses, and gone are the days in which IT was a cost-centre, and if the system went down then the work-force could revert to paper-based processes. Today's IT function is the core engine of high-performance businesses, and there is no paper-based fallback. When the network, or a vital server goes down, everybody stops work. Some right away, some continue for minutes, perhaps hours in some cases, but ultimately everyone stops work once they need something vital from the business's core systems. If your business is transacted over the web, then for every minute your infrastructure is not accessible to customers, you lose both money and vital brand equity.
As I've written before, COPQ or Cost Of Poor Quality is a significant drag on a businesses ability to innovate or improve. The principle mechanisms behind poor quality software production are systemic drivers (company culture, target-driven projects) and programmer skill. Changing and improving the Culture and System of an organisation are often outside the reach of the technical staff, but an individual's own skillset is their own responsibility, and therefore within reach of the individual to affect.
Unfortunately for the IT industry, the vast majority of academic institutions both in the US, UK and Europe do not teach modern programming methods e.g. collaborative development (including pair-programming), Test-Driven Development (TDD), Continuous Integration (CI), Refactoring and Simple Design. A straw poll amongst London's developer community shows that less than half of the developers work for organisations that routinely employ TDD, and only about 1 in 10 employ pair-programming. This low level of take-up means that developers often lack good on-the-job training from their employers, and their only recourse for learning efficient high-quality modern development techniques is to self-study in their own time.
Whilst working for Sourcesense I saw a need for a workshop-based format for improving developer skills through deliberate practice, rather than the more normal classroom-based "tell them what you're going to tell them, tell them, then tell them what you've told them". The reasoning for the choice of format was driven by the fact that like the game of Chess, explaining the 'rules' of TDD (or any other XP practice) takes only a minute or two, but mastering it can take years, and is principally driven by practice. In the book "Outliers" author Malcolm Gladwell identifies the "10,000 hour rule", the observation that independent of the field of study, it takes about 10,000 hours of deliberate practice to master the skill, and in order to count against the total the practice must be focussed, goal-directed, stretch one's abilities, give continuous feedback and be followed by self-reflection. Those 10,000 hours of deliberate practice can be difficult to obtain, as so much of our day-to-day work doesn't stretch us, isn't focussed, doesn't give us continuous feedback or we aren't allowed time for reflection.
In order to advance our skills, an environment that is dedicated to deliberate practice rather than delivery of value is a valuable resource, and this is exactly what a Code Dojo is.
During a Code Dojo we work in pairs, using TDD, Refactoring and adhering to the principles of Simple Design in order to solve a set-piece problem (or 'kata'). The focus is not on completing the problem in the time available, but rather doing the best job that you can, and improving your practice of the core techniques in doing so.