I've now finished "Zen and the Art of Motorcycle Maintenance". It is a good book, and quite thought provoking. Something that's stuck with me this time is "the gumption trap". Pirsig describes "gumption" as something akin to enthusiasm and writes that:

"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."

This is also so very true (at least in my experience) for software development. It's possible to plod away if you don't have gumption for what you're doing, but you won't accomplish much and likely will make a lot of errors that you'll have to fix later on. If you don't have gumption for a particular task, better to switch to something else for a little while then come back when you do. Gumption can, Pirsig writes, be loosely defined as "anything that causes one to lose sight of Quality, and thus lose one's enthusiam for what one is doing."

Pirsig goes on to describe several ways in which gumption i s sapped. They all seem relevant to software development. Pirsig divides gumption traps into two parts: Setbacks and value traps. Setbacks are caused by external circumstances and are the commonest gumption traps.

Some setbacks are:

• Out-of-sequence assembly. This is when the work is done in the wrong order. Forget an important interface? Now you have to go back and rewrite several core components. Feel your enthusiasm hissing away like air from a punctured tire.


• Intermittant failure. We've all seen this one. It doesn't work in production but you can't replicate the problem in development. You see something a case that *could* cause the particular problem, add some code to prevent that case from occurring and sit back thinking "problem solved" only to have your users report that the problem remains unfixed.


• Parts setback. This is an annoying one. Need a tool or component to continue work? Are you waiting for a coworker to finish his or her part of the project before you can continue on yours? Congratulations! You've lost gumption due to a parts setback.

Value traps are far more dangerous and are more diverse. Some value traps are:

• Value rigidity. This occurs when you've arrived at a solution, perhaps through a great deal of effort, that doesn't work. You are vested in that solution and because of committment to it are unable to consider other, perhaps simpler solutions.


• Another value trap is Ego. Pirsig points out that good mechanics are often humble folks--that the job makes them so because machines and problems do not respect previous accomplishments. When fixing a motorcycle one can not rest on one's laurels. The same is true for software development. When the facts show you've goofed, writes Pirsig, you're less likely to admit it if you suffer from the Ego value trap and you're more likely to accept false information if it makes you look good.


• The opposite of Ego is Anxiety. This occurs when you're afraid of doing something wrong, say on a very important production system. You're so nervous, so afraid breaking something that you don't do anything. When you're in such a situation and you find it very hard to get started, you're stuck in the Anxiety value trap.


• Like Ego, Boredom is dangerous. If you find it hard to become interested in a problem you are more likely to make mistakes and less likely to accomplish anything substantial.


• Impatience is always caused by an underappreciation for the amount of time that the job will take. There's nothing that will sap gumption like making a big mistake while trying to rush the job because of a poor estimate.

This is a really cursory overview of gumption traps but I think gumption is something many writers of books about management of software projects delve into. In particular, I think of Tom Demarco's book, "Peopleware" or perhaps even Brook's Mythical Man Month.