Zen and the Art of Software Development
“What follows is based on actual occurrences. Although much has been changed for rhetorical purposes, it must be regarded in its essence as fact. However, it should in no way be associated with that great body of factual information relating to orthodox Zen Buddhist practice. It’s not very factual on [software], either.
And what is good, Phædrus,
And what is not good…
Need we ask anyone to tell us these things?”
-Paraphrased R.M. Pirsig
This, ironically, is a post I’ve been looking forward to. “Zen and the Art of Motorcycle Maintenance” was one of my favorite books growing up, and while it’s no perfect form of philosophy, the subject it chooses to use as an example of ‘Romantic’ versus ‘Classic’ reasoning, technology, fits perfectly with software. Many of the things Pirsig says about technology, and this was back in the 60’s and 70’s, still fits today in software culture. This is not that surprising, as it’s well known that the classic “The Mythical Man Month” was written decades ago but it’s mistakes keep getting made.
The specific passages I’d like to discuss in this “Chautauqua” of sorts, is the discussion of Gumption traps to how software is developed. This is going to take more than a single post, so I’ll use this one to introduce some of the concepts.
First off is Pirsig’s concept of Quality. Pirsig writes quite a bit about Quality, even though he decides its undefinable. But the jist of what I understand, and what I’ve taken away from the book, is quality is what you get when someone competent cares about a project. In our work-ethic driven society, we so rarely remember that passion is not something you can just ‘try’ for, it’s just something that either exists or doesn’t in what you do. You cannot, in other words, try really hard to be passionate about something. You are either passionate about it, or you aren’t, and no ammount of nose-to-the-grindstone work is going to change that.
Quality in software, like quality in everything, remains undefined. But we can say some of the things that are closely correlated with Quality. Namely, a lack of software defects(bugs). Readability, maintainability, elegance.
When one sees an elegant solution to a problem, you cannot deny that the author of the solution didn’t care about the problem. It’s evident from the code! Indeed, I’d surmise that most of our bugs, most of our worst output comes from things we don’t care about. It’s cyclical, in that way. We loose passion in a thing, and then simply try and drive through it. But the code we write, and the designs we produce, during this non-caring state is absolutely pitiful, and we begin to build up technical debt. Because of this, we loose even more passion, and the process gets worse.
Waterfall, and other ‘processes’ are sort of a post-modern response to this. They implicitly acknowledge that designers will loose passion for what they work on, how do we best deal with that fact? Agile, however, takes a different approach in how to maximize passion for work. Honestly, they both have things to teach. But this post is not about software development processes.
Pirsig describes what he calls ‘gumption’ traps. Gumption is a folksy word, synonymous with ‘care’, and basically is the same thing as what we’ve been talking about. A person who cares about what they do is said to have gumption. Gumption traps, then, are common anti-patterns people run into in working on things they care about. Things that sap that care. Learning how to recognize and avoid them is key to fulfilling what one is cares about in the first place.
I’ll be discussing these gumption traps in future posts. But to surmise this gentle introduction to a folksy, modern beatnik philosophy of software development, let’s turn to another aspect of REAL software development we’re more familiar with.
The ‘zone’. You’ve experienced it playing video games and, if you’re lucky(and your employer is very lucky) you’ve experienced it on projects you work on. It’s when the mind becomes focused like a laser on the job at hand, and your productivity goes through the roof. Gumption is similar to the zone, but in an affective way. Gumption is what makes you want to be in the zone in the first place. Gumption is what drives you to finish a project just to see and use the results of your work in the real world, rather than artificial schedules and milestones. In fact, contrary to what some have said, when we are irritated that silly distractions pull us out of the ‘zone’ when we are working, we are not irritated for rational reasons. It is not the ‘zone’ mindset itself that is irritated. It is actually our gumption waning. Being pulled out of the zone is a major gumption trap in itself.
A good example of this is realizing that you really don’t mind being interrupted on a project you don’t care about. And when you realize you don’t mind being interrupted, as I hope I’ll show you through these “Chautauquas”, you’d be better off quitting altogether. Gumption, and caring, is what drives good software, and there is absolutely no process, no method, no trick or tool that will give it to you. You’ve just got to recognize when you have it, and realize it’s best to walk away when you don’t.
No comments yet.