Aikido, and I suppose all martial arts, are painful. Mostly physically painful, depending on how skilled – or rather, how unskilled – the person on the other end of your joint is. But there is also a great deal of figurative pain. It’s the pain of letting go of your ego and the pain of emptying your cup. It’s the acceptance that someone half your size (or less) can be twice (or more) as effective as you are, disabling and throwing you around seemingly without even trying. It’s understanding that no, it’s not as trivial as your teacher makes it look and that yes, it’s going to require work to do it effortlessly. A LOT of work.
In the years that I’ve been doing Aikido, I’ve seen many people come and go through our school doors. For some, it truly was physical – too much inter-personal contact, extra-sensitive joints and at least in one case, an almost-broken knee. But for the grand majority it was not. It was the inability to learn something ‘easy’ from someone else. These are the kind of people who came to teach junior students, rather than learn from the senior ones. In fact, one of the things I admire most about my teacher is his endless patience, which eventually resulted in many students changing from the former kind into the latter (myself included).
But this is a tech blog. So what’s all this talk of martial arts? Well, getting software quality to look effortless and easy takes work. A LOT of work. And with the state of the practice that I see at some software organizations today, it definitely feels like a battlefield. Here’s a typical scenario: a reasonably successful organization will happily spend days squeezing the last ounce of performance out of some algorithm. And they’ll readily acknowledge that they're not able to iterate quickly enough, or ship with a low enough number of bugs (zero-bugs policy, anyone?), or deliver on-time enough. Yet when the talk turns to actually doing something about it, the same organizations suddenly know everything there is to know, have done everything there is to do and can generally find a 6-digit number of reasons for why THEIR product quality simply CANNOT be improved.
So, if you’re not willing (notice I said willing – not a word about able) to change anything you’re doing today, what in the name of Miyamoto Musashi makes you think your quality will improve? What, some fairy will drop down from the sky and magically exorcise all bugs from your code? Yes, it IS as ridiculous as it sounds. Wearing a keikogi or not, I’m seeing the same type of people that cannot cut it in a dojo. You WILL have to write some kind of automated tests. You WILL have to set up some kind of automated build. And it’s going to take work. A LOT of work. Whether you eventually succeed or not depends on how empty your cup is and how much you’re willing to learn from others, be they younger, older, bigger or smaller than you.
So when someone approaches me at a conference, sends me an email or asks my advice I start by asking them two questions:
- What have you tried already?
- Why do want to do whatever it is that you want done?
The answer to #1 helps me make sure my cup is empty (well, not completely full is a good start…). It’s amazing how resourceful and smart people never cease to surprise me. My favorite answer to #2: ‘It hurts. How do I make it hurt less?’.