Analogies considered harmful?

Rachel Davies has written a thoughtful and thought-provoking article: Shu-Ha-Ri considered harmful? In it she captures the essence of what has been making me feel uncomfortable about the various Shu-Ha-Ri articles I’ve read – that Shu-Ha-Ri is a philosophy and teaching approach designed to help total novices in Aikido (and other martial arts; Aikido is a modern evolution of age-old Japanese traditions of both combat and teaching) achieve mastery of the art over a period of many years. What it is not is an approach for aiding functioning software teams or practitioners adopt new techniques that might help them in the short- to medium-term.

I’ve personally experienced the good and the bad of Shu-Ha-Ri as applied to martial arts. In seven years of Shotokan karate I started as a total novice, built strength and basic technique through constant repetition of stances, blocks, punches and kicks, and gradually evolved through some level of understanding to taking classes of new students. After a period of constant injury I could no longer practice karate so I took up Aikido. Sensei commented that I was a “deeply unusual student”: whilst I had a Ri level of appreciation of what I needed to learn and, more importantly, unlearn his usual approach to teaching wasn’t working for me. My karate technique, based on power and force rather than the balance and harmony of Aikido, was actively blocking my learning; even though I knew and understood this. Sensei had to take a different approach to teaching me than his other students which was ultimately only partially successful (due to my inability and struggle with injury rather than his teaching).

There is much that is beguiling in applying an analogous Shu-Ha-Ri system of learning to adopting agile software development practices and processes. How many old hands at XP suggest “just do the practices” as a good way to start? Isn’t an understanding of what stage of learning you’re at helpful when adopting any new process or practice? Equally, how many teams or practitioners come to agile as total software novices? How many of them already have a Ri-level of appreciation of software delivery that just happens not to be based on agile? How many of them are willing or able to subjugate themselves to the student/master relationship that Shu-Ha-Ri is built on? And how many coaches really have the experience it takes to become Sensei anyway?

In short, there’s some good and useful stuff to acknowledge about Shu-Ha-Ri but let’s not get carried away thinking that adopting agile is like becoming a white-belt in Aikido.

This is not the first time software practitioners got caught in the trap of a juicy looking analogy, nor will it be the last. Sometimes I wonder that, as practitioners of one of the world’s youngest disciplines we are desperate for approbation from and connection to the much older ones. When it was all about Architecture rather than Agile, the software-as-building analogy was everywhere. One of my favourite instances was someone at a conference explaining that the database was just like foundations of a house and then going on to explain that you should use stored procedures and triggers for business logic. Right, because most houses have 20′ deep foundations with all the important functional stuff in and only extend 2′ above ground. Which isn’t to say that we can’t learn from the built environment – Stuart Brand’s ‘How Buildings Learn’ has been far more influential on me in making agile development work in large organisations than anything else I read at the time or since – just that we should approach every analogy with trepidation.

Whenever I see something like the Shu-Ha-Ri articles, or the later and related articles on coding dojos and programming kata, I remind myself of the talk that Kent Beck gave at OT’99: “Software is Software”. Kent’s point was that software, and the people, processes and practices that combine to build it is a unique discipline. Sure we can, and should, learn from other disciplines but at every step of the way we have to beware getting carried away with the idea that what we do, or some aspect of it, is just like Aikido, or Architecture, or Civil Engineering, or Science, or Music, or Improv, or Manufacturing, or …


6 thoughts on “Analogies considered harmful?

  1. Mark Levison

    Paul – I think you’ve hit the nail on the head (to use another analogy). Many of these analogies are a useful starting point. The trick is knowing when to let go.

    I still have clients who have the opposite problem – they want to tinker with the agile practices on day 2. They ask why is this standup daily, 2-3 times a week sitting down should be enough.

    Mark Levison
    Agile Pain Relief Consultant

  2. Olga Kouzina

    Can’t help asking – Mark, why did you chose this name “Agile Pain Relief” consultant? Pain relievers do not remove the source of pain they just provide a temporary relief. Just like pain-killers. On to commenting the post – it’s a great point about temptation of juicy analogies. I think analogies will work better not for software development as such. Aikido, karate and tennis – which is a non-contact martial art, I’d say, and even more refined since there’s no immediate physical danger involved, but you still have to perform as in contact combat – are about building personal qualities. Building software is not about building personal qualities. But software is developed by teams and by persons. In this case, analogies with karate etc. will work great when you talk about building up a team as a one-functional unit. All for one – someone is a head, someone is brain, someone is hand etc. Creating software is an art, and it requires certain personal qualities – like other arts – so that’s basically the analogy.

  3. Pingback: Elegance is an Attitude | Edge of Chaos | Agile Development Blog

  4. Pingback: Shearing Layers in Software Delivery Part 3: Slippage « Paul Dyson’s Blog

  5. Pingback: JustaProgrammer Revisited « Paul Dyson’s Blog

  6. Pingback: An economic model of technical debt? « Paul Dyson’s Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s