author: @sleepyfox
title: Aikido and the philosophy of software development
date: 11-Oct-2013
I ran an impromptu session at the Software Craftsmanship and Testing conference in the UK a couple of weeks ago, that turned out to be rather well received - though I suspect that this was more due to the novelty of the session rather than anything else. The spark that led to this session was a tweet by James Coplien that both he and Jeff Sutherland practice Aikido, re-tweeted by Bob Marshall.
It led me to think that if one of the two founders of Scrum were positively influenced by Aikido, perhaps Aikido has had other influences within the IT world that we are perhaps unaware of, and perhaps it would be worth talking with people about.
I started Aikido in 1991. Since that time I've paracticed many martial arts, and certainly don't regard myself as a real expert in any of them, but even an evergreen beginner such as myself notices that there are quite a few similarities between software development and the martial arts.
Often at conferences and meetups I ask the question "How many of you practice a martial art of some sort?" and typically this is 30-40% or more - which although not a statistically provable correlation is at least empirical evidence that there is something worthy of investigation going on here..
Much of the language of modern software development, especially software craftsmanship, comes from Japanese martial arts, e.g.
- Dojo - a place of learning 'the way'
- Kata - an exercise designed to teach a particular skill or principle through repeated practice
- Shu/Ha/Ri - the stages of learning one goes through, analogous to Apprentice/Journeyman/Master
Since I started running the London Code Dojo in 2011, the idea of a meet-up where developers could come together and learn-by-doing has become way more popular and less 'wacky' than it was when I started. In London alone, we have the Scala Dojo, the Clojure Dojo, the Python Dojo, CoderDojo (for teaching kids) and a variety of others. Dojos are still a long way away from becoming mainstream, but they're definitely out of the 'innovator' space that they were when I started.
A code kata is a simple exercise that you solve as a way of learning a language or technique (e.g. test-driven development). The idea that you'd do one of these exercises more than the once I don't think ever occurred to me until I read Dave Thomas's blog (of 'Pragmatic Programmer' fame) on katas, which by the way was written in 2007. Suddenly, the congruence of code katas and martial arts katas 'clicked' and I understood that there was more than just a coincidental similarity in names, like between Java and JavaScript, or Gazelle and Gazebo.
The principle of the stages of learning - literally 'obey', 'detach', 'transcend' - is a traditional Japanese concept that is hundred of years old, and is at the core of the Aikido training regime. This is a common model in traditional Japanese arts, from Cha-do (the way of the tea ceremony) to Sho-do (traditional Japanese calligraphy). There is a great similarity here between the concepts in software craftsmanship of 'apprentice', 'journeyman', 'master' - so much so that the terms Shu, Ha, Ri are now part of the core lexicon of the software craftsmanship community. Alistair Cockburn is the first industry figure I know of to talk about ShuHaRi in 2001 to refer to the pattern of skill acquisition in software, though anyone who bridged the worlds of Aikido (or other traditional Japanese arts) and Software would be aware and possibly have used Shu Ha Ri in a software context. I strongly suspect that this happened many years previously in Japan, but the scarcity of fluent Japanese speakers in the English language sphere of influence blinds us to this.
Quite a bit of Japanese martial arts (or 'Budo') language seems to have been adopted by the software community (especially the software craftsmanship community), and I find it difficult to believe that this is solely the influence of the Ruby community - Ruby being created by a Japanese programmer, Yukihiro Matsumoto.
It is not just language, the importance of the concept of deliberate practice has been known about in martial arts for a very long time, and learning by doing is not just a choice, but a necessity due to the very physical and personal nature of training.
A key practice of Aikido is pairing. After a group has come together to train, and the instructor has demonstrated a technique, the class will split into pairs to practice the technique. One of the pair ('Uke' - the receiver) plays the attacker, whose movement provides the opportunity for the other partner ('Nage' - the thrower) to practice the technique. The pair will swap roles, helping each other learn both how to do the technique, and how to break-fall safely to receive the technique without harm. Whilst other martial arts do use pairing as a learning tool, Aikido is one of the few to use it almost exclusively as the only way to learn. Aikido's approach to pairing is almost identical in feel, principle and purpose to pair-programming from Agile software development.
Furthermore, it turns out that Aikido - which may be translated as 'The way of harmony with nature' - is not your usual martial art, but something that aspires to be an almost oxymoronic 'non-violent martial art'. Aikido's particular slant on solving conflict through 'not-fighting' is reminiscent of Marshall Rosenberg's Non-Violent Communication, and has some particularly relevant applications to solving workplace conflicts that we as software developers often find ourselves in, perhaps due to differing patterns of thought and belief systems from others in the organisations that we often work within.
However, it was not Aikido's methods of conflict resolution that interested me most - though I do find them very interesting - but rather its underlying principles and axioms, and the way that its methods of thinking are analogous to, or may inform or extend, the ways of thinking that we use day-to-day as software developers.
First let me explain what I mean by 'thinking tool'. A design pattern is a way of solving a problem, that may be applied to many different kinds of problems, and that has a certain set of indications or contra-indications dependant on context. A (singular) design pattern is not what I mean by a 'thinking tool'; the predisposition to looking for and applying design patterns as a way of solving problems is an example of what I mean by a 'thinking tool'.
There are two specific core concepts or thinking tools from Aikido that I'd like to explore in more detail:
The concept of irime - literally 'entering the body' - is one of the fundamental principles in Aikido. In the moment of an enemy's attack the Aikido practitioner moves to a position of most advantage and applies their technique to the point of the attacker's balance where they are weakest, but from a position of the practitioner's strength. It is this positioning in three dimensions and relative to the particular body-mechanics of both attacker and practitioner that leads what seems to be so gentle a technique to be so incredibly effective, the technique's effectiveness has been magnified many times by the application of leverage and simple mechanics - but in a way that is as elegant as a ballet dancer. Kjarten Clausen, maintainer of the aikido-l archives and the Aikido FAQ during the 1990s (to whom I and many others owe a huge debt of gratitude) liked to call Aikido 'Origami, but with people instead of paper'.
Being able to see the line of most advantageous attack, and positioning oneself to most effectively take advantage of it, in the instant of the opponent's motion, is analogous to seeing a problem, and at once designing a solution to most effectively solve it. Or perhaps seeing the most-risky part of a solution and designing a technical spike to mitigate or expose that risk so that the team can take appropriate action early, whilst there are still choices available.
Tenkan - literally 'turning' - are ways in Aikido of using the action of turning the body to deflect an oncoming attack harmlessly and without effort, as a prequel to a technique. One can think of it as pushing on the centre of a bicycle wheel that has been turned on its side. Pushing against the edge of the wheel directly towards the wheel's centre produces no result (assuming the wheel is firmly fixed), but the moment you push in a direction slightly to one side or the other of the centre, the wheel quickly turns and deflects the force of your push (a key concept here is that the wheel did not choose to turn).
This technique can also be applied as a thinking technique, when one finds oneself blocked in a particular line of thinking, turning away e.g. by solving an oblique problem, often leads to an insight that enables one to avoid having to solve the initial problem at all, or renders the initial problem harmless. In this way 'letting go' of the desire to enter into conflict with the initial problem (us and them both pushing against each other) helps us to move forwards. In a conflict of person vs. person, this tenkan technique can enable us to give up something we don't value, in order that both parties can get to what they need i.e. a win-win resolution.
There are many other thinking principles of Aikido that we can apply to our toolbox of thought processes that we use in our daily work as software developers, but these will have to wait for another time.
P.S. It appears that I'm not the only one who thinks that software development, particularly modern software development methods like software craftsmanship or Agile development, are analogous to Aikido: Agile Methodology: the Aikido of the Companies
Update 2013-10-10 It appears that David J. Anderson's keynote to the Lean Kanban Netherlands 2013 conference on "Lessons we can learn from Bruce Lee's journey in the Martial Arts" also supports my hypothesis.