June 11, 2015 · books

Zen and the Art of Motorcycle Maintenance

During my last holiday I reread Zen and the Art of Motorcycle Maintenance, one of my favourite books. In some parts it might be a bit obscure, so I tried to reframe it through the lens of software engineering. And indeed it made it much more relatable, specially around three quarters in the book, where it talks about quality and gumption. Let's see some examples.

The book cover

Some things you miss because they're so tiny you overlook them. But some things you don't see because they're so huge. We were both looking at the same thing, seeing the same thing, talking about the same thing, thinking about the same thing, except he was looking, seeing, talking and thinking from a completely different dimension.

Ever talked with a product owner or a customer and felt that you where talking about different things?


I think it's important now to tie care to Quality by pointing out that care and Quality are internal and external aspects of the same thing. A person who sees Quality and feels it as he works is a person who cares. A person who cares about what he sees and does is a person who's bound to have some characteristics of Quality.

In my experience this is very true. The best engineers I've worked with are the ones who care. The ones who don't stop until they find the root cause of a bug. The ones who leave the code better than they found it.


Quality isn't something you lay on top of subjects and objects like tinsel on a Christmas tree. Real Quality must be the source of the subjects and objects, the cone from which the tree must start.

In the software world we learned that many years ago. That's why the use of agile methodologies, continuous integration and tests it's so widespread nowadays.


If you're going to repair a motorcycle, an adequate supply of gumption is the first and most important tool. If you haven't got that you might as well gather up all the other tools and put them away, because they won't do you any good. [...] If you haven't got it there's no way the motorcycle can possibly be fixed. But if you have got it and know how to keep it there's absolutely no way in this whole world that motorcycle can keep from getting fixed. It's bound to happen. Therefore the thing that must be monitored at all times and preserved before anything else is the gumption.

Indeed, if you're in a hurry to fix a bug and move on is likely that you will end up fixing the symptoms and not the root causes. Or causing another bug while fixing it.

Fortunately with software, unlike motorbikes, you can easily use tests to reproduce bugs before fixing them.


If you have a high evaluation of yourself then your ability to recognize new facts is weakened. Your ego isolates you from the Quality reality. When the facts show that you've just goofed, you're not as likely to admit it. When false information makes you look good, you're likely to believe it. On any mechanical repair job ego comes in for rough treatment. You're always being fooled, you're always making mistakes, and a mechanic who has a big ego to defend is at a terrific disadvantage.

Pirsing describes a number of "gumption traps", as he calls them, but ego is the one that I find more interesting. It's very easy to identify yourself with the work you do and get defensive when someone criticises it. Pretty much everyone has been at this position when getting a code review or after introducing a dumb bug.


You want to know how to paint a perfect painting? It's easy. Make yourself perfect and then just paint naturally. Thats the way all the experts do it. The making of a painting or the fixing of a motorcycle isn't separate from the rest of your existence. If you're a sloppy thinker the six days of the week you aren't working on your machine, what trap avoidances, what gimmicks, can make you all of a sudden sharp on the seventh? It all goes together. [...] The real cycle you're working on is a cycle called yourself. The machine that appears to be "out there" and the person that appears to be "in here" are not two separate things. They grow toward Quality or fall away from Quality together.

You don't work on some code, you work on yourself. I find this thought really interesting, and it's also in line with the software craftsmanship manifesto.


I hope that you enjoyed these ideas as much as I did. Apart from that, the book has a really engaging story behind it, so I encourage you to read it!

Comments powered by Disqus