Some people think that Zen and the Art of Motorcycle Maintenance (ZAMM) is rubbish; others think it is a life changing work with profound implications. I read the book eons ago but was reminded by my son that it is about the nature of quality among other things (like taking a 10 year old on an ill-advised motorcycle trip across the country, for one). While I am most certain that when he wrote ZAMM, Robert Pirsig did not have software quality in mind, it is nevertheless interesting to contemplate his notion of a classical as opposed to a romantic view of quality. Of course, I am not the first, nor will I be the last to quote from this work, and at the risk of completely misrepresenting Pirsig, neither am I the only person to refer to his romantic/classical references to quality as it applies to software.
A romantic, forever living in the moment, will not be concerned about his motorcycle if it is working right now. If the software works, nothing else matters. “Let the user find the defects”. The classical view, however, is concerned about the future as well as the present (and the past). The classicist in a software team will be obsessed about technical debt because he knows that not checking the oil every time you fuel up is just asking for trouble. The software must be pristine before getting shipped. No technical debt. Period.
We have all known programmers on this spectrum. The purist who insists on documenting everything, testing everything, and insisting on following coding standards to the letter. And the “practical” guy who is more concerned about hitting the deadlines and doing whatever he can do make the software work. In some cases, the hero! Obviously, and as always, the practical middle ground rules the day.
This is naturally a caricature. Pirsig challenges the reader about the nature of quality. Is it objective? Not really – there are no instruments to measure quality. Or is it subjective? In which case quality is in the eye of the beholder and maybe even meaningless.
In software development, fortunately, we don’t have to gaze at the naval quite so deeply. With visibility and governance tools, static code analysis, test coverage, and most importantly, an understanding of the real impact of technical debt in an organization, all personality types on this spectrum can be happy and well served. We can all agree that as far as the quality of a piece of software is concerned, the minimum standard is the adherence to at least the most critical of quality best practises. Adherence to naming conventions, for instance, may not matter as much as making sure that database statements are well written.
We can help the classicist – who has a deep desire to adhere to all coding standards – by focusing on the most important if a project schedule is challenged, and documenting the rest. At least he will rest assured that the small landmines are documented and will be dealt with somehow: intentional technical debt – sometimes necessary to hit the market windows – but never a good idea if not done with eyes wide open. The romantic, on the other hand, can also look at the same standards and rest assured that his practical bent is valued, but not at the risk of explosions on go-live.
No matter what you think of Pirsig’s view of quality as a metaphysical concept, when we roll up the sleeves and build complex software, we don’t have to spend too much time naval gazing, and wondering about the ultimate nature of quality.
Sometimes the first step is the most important. Just putting a ‘quality fence‘ around the source code so the team adheres to basic, well known best practices will eliminate most of your headaches. It will prevent the romantics from straying too far from best practices but still help the schedules; it will help the obsessed classicists from their relentless pursuit of an ideal. It will get the job done, eliminate wasted cycles in QA and make the customer happy.
What do you think? Are you a classicist? A romantic? Or somewhere in the middle?
*Featured image courtesy of Amazon