Improving Development Gumption

• 03/10/1999

In the 1974 tour-de-force Zen and the Art of Motorcycle Maintenance, Robert Pirsig takes his readers on a philosophical and psychological journey across the country in the saddle of a well-maintained motorbike. Pirsig's meticulous upkeep of the bike is an analogy for living a contented life. When I traded in a 1979 Kawasaki KZ1000 for a modern sport-touring machine, I also traded away a lot of wrench turning. But many of Pirsig’s words still hit home, this time with the software developer in me. The chapter most relevant to my programmer’s mind deals with avoiding "gumption traps."

Software development is comparable to motorcycle maintenance in some ways. Shop manuals exist for nearly every bike, but reading a shop manual does not make you a mechanic. Similarly, reading a programming manual does not make you a programmer. In addition to a logical mind, a willingness to create, and a good understanding of the desired solution, a programmer must have gumption. Pirsig describes gumption as the psychic gasoline that keeps the problem-solving process going. While some seem to be born with an abundance of gumption, gumption is not an endless commodity. Increasing the reservoir of good spirits comes from avoiding traps that suck the gumption out of you.

The first gumption trap described for motorcycle repair is the out-of-sequence assembly trap -- that sinking feeling of finding a leftover part after you’ve reconstructed an assembly. You can feel your gumption deflate. Developers face similar problems during integration: overwriting other people’s code, only partially integrating your own changes, or wiping out the file on which you’re working. For developers, this gumption trap is best avoided by consistently using source control and backups. The knowledge that you can recover any previous version of a project is a powerful way to keep your gumption high.

Pirsig’s study of gumptionology continues with a discussion about intermittent failure -- a problem that fixes itself without explanation. The trap, of course, is that we fool ourselves into thinking we’ve fixed the problem when, in fact, it will eventually happen again. A person maintaining his own machine is at a big advantage here because intermittent bugs are best studied by extended use of the product, which is easier when its your own motorcycle. In the world of programming, however, it is far less common that a commercial developer actually uses the product that he or she develops.

The first goal of repairing intermittent failures is consistently recreating them, perhaps using a script and starting with a reboot. Once a bug occurs 100 percent of the time, it is no longer intermittent. Tools like just-in-time (JIT) debuggers can help by letting you run a program normally, activating the debugger only when the intermittent error occurs. A stack trace can then provide a playback of the history leading to the bug. The last thing that should be blamed is the operating system, compiler or IDE. Although these components do have bugs, my experience is that 99.5 percent of all bugs I’ve hunted have been the fault of the code. Blaming the O/S is usually a trap.

A sticky trap for both developers and motorcycle maintainers is the parts problem. Software developers have difficult part choices to make. Unlike a motorcycle, in which the major tasks are determining the right part and deciding on buying a new part vs. a used part, developers have many more choices. Pirsig describes the pleasure of machining a custom part for his bike, but he never suggests that you might create an entire motorcycle from scratch. Developers are faced with that choice every day. Build or buy? Buying is a quick solution, but it means understanding price and licensing issues, giving up control of that component, and working with someone else’s code. Building a custom solution can be more interesting, but it is often slow going with indeterminate costs. The custom solution may be precisely right for the circumstances, but the resulting documentation and extensibility may be poor or non-existent.

The parts problem is best dealt with by measuring your company’s ability to develop custom solutions so that you can better estimate the tradeoffs. If you have a good experience with a component supplier, cultivate that relationship and use it to your advantage. Confidence about build-or-buy decisions helps avoid this potential trap.

The early days of PC computing were filled with stories of individual programmers making heroic efforts to create the products that shaped our industry. The care with which they brought those early products to market is reminiscent of the care taken by a dedicated biker tweaking his idle and polishing his chrome. While those days may be gone from this industry forever, Pirsig’s lessons for improving the quality of the man/machine relationship still apply. --Eric Binary Anderson is a development manager at PeopleSoft's PeopleTools division (Pleasanton, Calif.) and has his own consulting business, Binary Solutions. Contact him at ebinary@yahoo.com.