Not long ago, I (finally) read Zen and the Art of Motorcycle Maintenance, which I’d had recommended to me since I was a teenager. It’s a very interesting book and one I would certainly recommend to anyone, but especially to anyone with an interest in quality. Quality is one of the recurring themes of the book, and there are a number of sections of the book that resonate with me as a software craftsman attempting to improve the quality of the work I produce and the work my team produces.

One passage from the book really resonated with me in terms of the difference between workers who really care about what they’re doing, compared to those who do not. In all honesty I’ve never worked in a software development environment like the shop the author describes in this passage, but I do imagine they exist, and in any case the point he makes I think is worth keeping in mind regardless of the specific circumstances.

Note that I’m not at all handy, nor have I had the opportunity to ever ride a motorcycle. If the book’s reference to motorcycle maintenance have in the past kept it outside your reading list for reasons having to do with your own experience, please don’t let that put you off. It’s a very interesting read, and no knowledge of motorcycles is required (the section below probably contains more information about motorcycle maintenance, in detail, then the rest of the book).

The shop was a different scene from the ones I remembered. The mechanics, who had once all seemed like ancient veterans, now looked like children. A radio was going full blast and they were clowning around and talking and seemed not to notice me. When one of them finally came over he barely listened to the piston slap before saying, “Oh yeah. Tappets”

Tappets? I should have known then what was coming.

Two weeks later I paid their bill for 140 dollars, rode the cycle carefully at varying low speeds to wear it in and then after one thousand miles opened it up. At about seventy-five it seized again and freed at thirty, the same as before. When I brought it back they accused me of not breaking it in properly, but after much argument agreed to look into it. They overhauled it again and this time took it out themselves for a high-speed road test.

It seized on them this time.

After the third overhaul two months later they replaced the cylinders, put in oversize main carburetor jets, retarded the timing to make it run as coolly as possible and told me, “Don’t run it fast.”

It was covered with grease and did not start. I found the plugs were disconnected, connected them and started it, and now there really was a tappet noise. They hadn’t adjusted them. I pointed this out and the kid came with an open-end adjustable wrench, set wrong, and swiftly rounded both of the sheet-aluminum tappet covers, ruining both of them.

“I hope we’ve got some more of those in stock,” he said.

I nodded.

He brought out a hammer and cold chisel and started to pound them loose. The chisel punched through the aluminum cover and I could see he was pounding the chisel right into the engine head. On the next blow he missed the chisel completely and struck the head with the hammer, breaking off a portion of two of the cooling fins.

“Just stop,” I said politely, feeling this was a bad dream. “Just give me some new covers and I’ll take it the way it is.”

I got out of there as fast as possible, noisy tappets, shot tappet covers, greasy machine, down the road, and then felt a bad vibration at speeds over twenty. At the curb I discovered two of the four engine-mounting bolts were missing and a nut was missing from the third. The whole engine was hanging on by only one bolt. The overhead-cam chain-tensioner bolt was also missing, meaning it would have been hopeless to adjust the tappets anyway. Nightmare.

The thought thought of John putting his BMW into the hands of one of those people is something I have never brought up with him. Maybe I should.

I found the cause of the seizures a few weeks later, waiting to happen again. It was a little twenty-five-cent pin in the internal oil-delivery system that had been sheared and was preventing oil from reaching the head at high speeds.

The question why comes back again and again and has become a major reason for wanting to deliver this Chautauqua. Why did they butcher it so? These were not people running away from technology, like John and Sylvia. These were the technologists themselves. They sat down to do a job and they performed it like chimpanzees. Nothing personal in it. There was no obvious reason for it. And I tried to think back into that shop, that nightmare place, to try to remember anything that could have been the cause.

The radio was a clue. You can’t really think hard about what you’re doing and listen to the radio at the same time. Maybe they didn’t see their job as having anything to do with hard thought, just wrench twiddling. If you can twiddle wrenches while listening to the radio that’s more enjoyable.

Their speed was another clue. They were really slopping things around in a hurry and not looking where they slopped them. More money that way—if you don’t stop to think that it usually takes longer or comes out worse.

But the biggest clue seemed to be their expressions. They were hard to explain. Good-natured, friendly, easygoing—and uninvolved. They were like spectators. You had the feeling they had just wandered in there themselves and somebody had handed them a wrench. There was no identification with the job. No saying, “I am a mechanic.” At 5 P.M. or whenever their eight hours were in, you knew they would cut it off and not have another thought about their work. They were already trying not to have any thoughts about their work on the job. In their own way they were achieving the same thing John and Sylvia were, living with technology without really having anything to do with it. Or rather, they had something to do with it, but their own selves were outside of it, detached, removed. They were involved in it but not in such a way as to care.

Not only did these mechanics not find that sheared pin, but it was clearly a mechanic who had sheared it in the first place, by assembling the side cover plate improperly. I remembered the previous owner had said a mechanic had told him the plate was hard to get on. That was why. The shop manual had warned about this, but like the others he was probably in too much of a hurry or he didn’t care.

…We were all spectators. And it occurred to me there is no manual that deals with the real business of motorcycle maintenance, the most important aspect of all. Caring about what you are doing is considered either unimportant or taken for granted.

How does this relate to software development? Can we relate to moving fast and trying to patch something with a quick and dirty hack? Can

we relate the attitude of some developers compared to others, their passion, their attention to detail, their ability to think deeply about the problem at hand? Most of all, do we care about what we’re working on? If so, does that make all the difference? If not, why not? What can we do to ensure we and everyone else on our teams care about the work we are doing? It seems reasonable to me that caring and quality are correlated, though of course I understand correlation does not imply causation.

In relation to software craftsmanship and quality, one thing I think we can do to keep quality and care in mind as we perform our work is to consider our workplace. The proper tools, furniture, workspace, etc. are all important and help ensure the team is free from distractions and impediments to doing their best work. It may also be worthwhile to keep reminders of how the team does work, in terms of principles, patterns, and practices, as well as project-specific materials (kanban boards, burndown charts, etc) highly visible in the teams’ workspace. These information radiators communicate to the team as well as to anyone else entering the team’s workspace about project status as well as the kind of work this team is committed to doing.

Posters and calendars can be a cost-effective way to keep important principles in mind. Custom painting of certain rules, quotes, or practices on the walls is another. If you’re looking to add something like this to your own space, consider picking up a software craftsmanship calendar, which includes nice prints of twelve ideals of software development, as well as the software craftsmanship manifesto and the agile manifesto. You can order one now, or there’s a twitter contest going on until next month that you can enter to win one for free (if you’re reading this long after 13 November 2010, look for an updated calendar and other software craftsmanship products here). Once the month is done, pull out your favorite pages and post them in your office, team room, or cubicle.

More than anything, the biggest thing you can do to improve yourself as a craftsman in anything you do is to care. If you care, you’ll think harder about the problem, you’ll stick with it longer, you’ll work to improve your own knowledge on your own time to better prepare yourself for the work you do. If you don’t care, you’re probably not even reading this, but if you are, think about whether your time would be better spent for all concerned if you were doing something you were passionate about.