And What is Good Software, Phaedrus?

Published: 2024-06-10

Tagged: software essay

This is more loose musings about Robert Pirsig's "Zen and the Art of Motorcycle Maintenance" (ZAMM). The previous part focused on rhetoric.

Did you ever notice how Pirsig keeps coming back to the topic of baggage? There's packing and unpacking, of course--it's a road trip. But there's also plenty of loosening and tightening, especially when "things have shifted inside." And when there's too much of that "shifting", there's even an occasional repacking.

Baggage is simply a tax you pay for going away. It's never the end goal. But so much depends on it. A missing document, a ripped bag, a forgotten tool--any one of these can cast a shadow on the whole experience--or lead to canceling it altogether.

At one point in ZAMM the narrator discovers that a tube of sunscreen burst inside one of the bags. His things are covered in slimy, stinky cream. An awful mess. I bet sunscreen from the 70's was even more greasy and nasty than the stuff we got today. I feel a pulse of empathetic frustration.

But the narrator doesn't express anything like that. He just takes out a pocket notebook and writes down a reminder to buy a tackle box since tubes aren't likely to break. At that, my frustration is replaced by serenity.

There's something of a craft in packing for trips. Every time you do it, you need to make a hundred little decisions about what to pack, how, and where. Later, when you're in strange country, you face every one of those decisions. You're at your own mercy.

Making software involves a lot of the same kind of craft. Small things, choices, that repeat across projects, roles, and jobs. They're never the primary goal, but they always have an outsized impact on it.

There was, and maybe still is, a tiny subculture in the software industry centered on craft. I'm thinking of names like Fowler and Martin and Metz; Titles like "Refactoring" and "99 Bottles of OOP" and (deep breath) "Growing Object-Oriented Software Guides by Tests." If those don't ring any bells, maybe the name of Rich Hickey will--his talk, "Simple Made Easy", is a gem worth revisiting regularly.

This subculture revolved around the small things: How to name variables and functions; How to tease out concepts from code; How to structure and restructure programs; How to make better use of your tools; How to produce better estimates; How to get unstuck; How to say "no."

There's more. But there's nothing about, say, designing an auction service or migrating a legacy system to the cloud. Those are primary goals. Nobody starts on that kind of job in order to name things nicely or write really good tests. Nobody goes on a road trip just for the sake of packing baggage. But the small things are what decides how everything will go.

Consider how daunting it is to make software. Despite all the research, best practices, experience, training, and a growing wealth of helpful resources, most projects are late--if finished at all. There's just so many decisions and unknowns.

It's funny how enterprise'y solutions all promise to solve this problem. And yet most projects are late. Someone's lying (hopefully out of ignorance). But what's really interesting is the contrast between these approaches and software craftsmanship.

These over-hyped solutions start with a big abstract blueprint that can be customized to fit to any software project. Doesn't matter if it's a new video game or a social network for dogs. The cynical little devil on my shoulder says this is a fundamental feature of this business model because then, when a project inevitably doesn't work out, the guru can always claim that you just didn't implement the blueprint well enough.

But software craftsmanship takes the opposite approach. It states flat out that we don't know how to get to the finish line. What we can do is take things one step at a time, learn, and adjust our plans as we go along. That's why so much of the craft centers on the small things: because you don't know what you're going to be doing with today's code in two weeks time. So make it easy to change. Be kind to future-you and name things right. Every little thing helps.

It's surprising how small this craft subculture is. The broader software community produces endless books about learning new languages or databases or frameworks. But if I try real hard and cast a wide net, I can come up with what, a dozen and a few titles that talk about craft.

That used to make me mad. Mad as hell.

...and I'm not going to take it anymore! (Network, 1976)

I knew it was irrational. But I felt powerless and like I was being suffocated. Everywhere around me I saw slow, buggy software seeping into everything, infesting everything with frustrating delays and errors. Helpless cashiers waiting for their registers to reboot. Train schedules displaying the Windows desktop instead of departures and arrivals. Registration forms rejecting any but the most vanilla plain inputs--fuck you if your name had an accent or simply too many letters.

This monstrosity seemed unstoppable. It fed on every human frailty, every short-term decision, every little morsel of ignorance--and magnified it a million-fold through the globe-spanning network that we built, thinking that finally, it would connect every human to every other human and usher us into a better, kinder era.

With time, however, came the realization that I'm as much part of the problem as any other software developer. I had bad days. Also days when I just wanted to finish up and join the others at the bar. Other days I thought I knew what I was doing when I didn't. I occasionally got carried away and wrote code that was fun for me, but not much use for the user. Many a time I finished a boring task just well enough to call it done.

Early in ZAMM, Pirsig has the narrator try and explain Quality to his friends, the Sutherlands and the Deweeses. He begins with, "Assembly of Japanese bicycle requires great peace of mind."

I had little of that peace in me. My craft was poor. The books I had read, the ones I mentioned earlier, could only gesture in some vague direction. Ultimately, I needed to decide to travel that way--and to pack my bags well, and name my variables right.

And what is good software, Phædrus,

And what is not good software...

Need we fucking ask anyone to tell us these things?