There are a lot of lessons in the book that I think particularly apply to a personal philosophy of software development:
This one in which Phaedrus provides advice on how to deal with writer’s block is my personal favorite and applies to any project that seems overwhecould also apply to working on a difficult project. In the passage, “Phaedrus” is trying to help a student write an essay.
“….a girl with strong-lensed glasses, wanted to write a five-hundred-word essay about the United States.” He was used to the sinking feeling that comes from statements like this, and suggested without disparagement that she narrow it down to just Bozeman.”
However, the student still struggled:
“When the paper came due she didn’t have it and was quite upset. She had tried and tried and she just couldn’t think of anything to say.”
Phaedrus grew frustrated:
“It just stumped him. Now he couldn’t think of anything to say. A silence occurred, and then a peculiar answer: ‘Narrow it down to the main street of Bozemen.’ It was a stroke of insight.”
However the student returned again to him empty-handed:
“Narrow it down to the front of one building on the main street of Bozeman. The Opera House. Start with the upper left-hand brick.”
This worked, and the student returned with a 5,000 word essay.
I think the same approach can work with software. Sometime’s we’re tasked with designing software that does “X”, where “X” is something that is intimidatingly complex. Instead of struggling with the entire “X”, sometimes it’s helpful to focus on some small subset of “X”. Even if we throw away that first iteration, it got us moving, built momentum, helped us tackle the task.
To put it in more concrete terms: If you want to build a factory, or fix a motorcycle, or set a nation right without getting stuck, then classical, structured dualistic subject-object knowledge, although necessary, isn’t enough. You have to have some feeling for the quality of the work. You have to have a sense of what’s good. That is what carries you forward. This sense isn’t just something you’re born with, although you are born with it. it’s also something you can develop. It’s not just “intuition,” not just unexplainable “skill” or “talent.” It’s the direct result of contact with basic reality, Quality, which dualistic reason has in the past tended to conceal.
I think this passage helps to explain why it’s hard to work on something that you don’t understand. If you don’t know what it’s for, if you don’t know how it will be used, then it’s hard to have that sense of Quality about which Pirsig writes. I think this is what goes wrong with a lot of outsourcing projects. Developers are assigned to work on complex tasks for which they have no sense of Quality. In a more practical sense, this might mean coming to a junction where there are a couple of possible solutions, each with different ramifications. Which is the best solution? Without a sense of Quality, of how the solution should fit together, about what is good for the solution, then it can be difficult to pick the right path forward.
Pirsig describes “gumption” like this: “It’s variable, a reservoir of good spirits that can be added to or subtracted from. Since it’s a result of the perception of Quality, a gumption trap, consequently, can be defined as anything that causes one to lose sight of Quality, and thus lose one’s enthusiasm from what one is doing.”
To be sure, it’s much easier to work on something for which you have enthusiasm. To work on something for which you do not have enthusiasm can be painful, sometimes excruciatingly so.
There are lots of ways to lose enthusiasm for a project:
But there’s another kind of detail that no shop manual goes into but that is common to all machines and can be given here. This is the detail of the Quality relationship, the gumption relationship, between the machine and the mechanic, which is just as intricate as the machine itself. Throughout the process of fixing the machine things always come up, low-quality things, from a dusted knuckle to an accidentally ruined “irreplaceable” assembly. These drain off gumption, destroy enthusiasm and leave you so discouraged you want to forget the whole business. I call these things “gumption traps.” There are hundreds of different kinds of gumption traps, maybe thousands, maybe millions…
Note that Pirsig doesn’t include noisy neighbors in adjacent cubicles (or desks in an open office environment), ringing phones, or urgent emails. There’s another book called “Peopleware” by Tom Demarco that does a great job of identifying the sorts of environmental issues that decimate gumption.
There are other types of gumption traps. Who hasn’t put a few hours into a solution then realized they were on the wrong limb of the wrong tree in the wrong forest, and had to back up. Isn’t it a terrible feeling to waste all that effort and have to start over? That’s a gumption trap:
The second type is traps in which you’re thrown off the Quality track by conditions that are primarily within yourself. These I don’t have any generic name for – “hang-ups,” I suppose. I’ll take up the externally caused setbacks first.
The first time you do any major job it seems as though the out-of-sequence-reassembly setback is your biggest worry. This occurs usually at a time when you think you’re almost done. After days of work you finally have it all together except for: What’s this? A connecting-rod bearing liner?! How could you have left that out? Oh Jesus, everything’s got to come apart again! You can almost hear the gumption escaping. Psssssssssssssss.
There’s nothing you can do but go back and take it apart again… after a rest period of up to a month that allows you to get used to the idea.
Unfortunately, few of us get that month-long rest period when we make a mistake…
Types of Mechanics
There are bad mechanics. Although Pirsig is describing mechanics, we’ve all seen technicians in other fields who operate in this same manner:
I took this machine into a shop because I thought it wasn’t important enough to justify getting into myself, having to learn all the complicated details and maybe having to order parts and special tools and all that time-dragging stuff when I could get someone else to do it in less time…sort of John’s attitude.
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 befo
re 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.
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 try to adjust the tappets anyway. Nightmare.
The 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.
If I had to guess, I’d guess that “bad mechanics” was what went wrong with QuarkXPress’ outsourcing project:
There are a lot of photographic-mind software developers. If you think a garage floor can be messy and disorganized, with tools and parts scattered around in no apparent order, imagine how messy and disorganized a software application can be.
Inside I see that Bill is a mechanic of the “photographic mind” school. Everything lying around everywhere. Wrenches, screwdrivers, old parts, old motorcycles, new parts, new motorcycles, sales literature, inner tubes, all scattered so thickly and clutteredly you can’t even see the workbenches under them. I couldn’t work in conditions like this but that’s just because I’m not a photographic-mind mechanic. Bill can probably turn around and put his hand on any tool in this mess without having to think about where it is. I’ve seen mechanics like that. Drive you crazy to watch them, but they get the job done just as well and sometimes faster. Move one tool three inches to the left, though, and he’ll have to spend three days looking for it.
I think component-based architecture has ameliorated a lot of the danger to maintainability that photographic-mind software developers present. Still, these developers remain, and every so often you’ll have to work on code created by one…
Phaedrus is riding with his friend John. John has a new BMW motorcycle. Unfortunately, the handlebars on that new BMW have started slipping. Phaedrus proposes fixing the handlebars with a shim made out of piece of beer-can aluminum but John is mortified.
But to my surprise he didn’t see the cleverness of this at all. In fact he got noticeably haughty about the whole thing. Pretty soon he was dodging and filling with all kinds of excuses and, before I realized what his real attitude was, we had decided not to fix the handlebars after all…
What happened was that:
What emerged in vague form at first and then in sharper outline was the explanation that I had been seeing that shim in a kind of intellectual, rational, cerebral way in which the scientific properties of the metal were all that counted. John was going at it immediately and intuitively, grooving on it. I was going at it in terms of underlying form. He was going at it in terms of immediate appearance. I was seeing what the shim meant. He was seeing what the shim was. That’s how I arrived at that distinction. And when you see what this shim is, in this cause it’s depressing. Who likes to think of a beautiful precision machine fixed with an old hunk of junk?
So many times a discussion starts with the question “which of these options should we choose” and ends up as an architecture hang-up, with one side choosing the pragmatic beer-can-shim option, and the other holding out for the elegant design. Neither side budges an inch, tension builds and the boss is called in to mediate.
What often happens is that neither of the two sides has the big picture in view, which usually is working software in the customers’ hands.
Art and Zen
What I really like about this book is more an overarching concept than anything specifically written by Pirsig. I like to feel that I’m a craftsman, a skilled mechanic working on giant machines which, though virtual, are still machines.
There is definitely a Zen aspect involved in identifying and rectifying problems. An error message that you’ve never seen before reminds you of one you have, which gives you the essential clue to fixing the issue. An almost sixth sense compels you to try a test which leads you to the root problem. As you code, you instinctively plan and and account for conditions which shouldn’t happen but sometimes do…
And there is a great deal of satisfaction to be had in finding and fixing a particularly persnickety bug, or creating software which resolves a very arcane and difficult issue.