Edwin Fine recently posted on amazon.com a review of my book Code Quality: The Open Source Perspective. In the review he complained about the quality of proofreading and copy editing. (The errors he noted are now listed in the book's errata.) His comments sparked off a delightful discussion on the reasons behind the falling quality levels of various products, the philosophical importance of this phenomenon, and its effect on coding standards.
This in itself is merely irritating; the real concern I have is that it points to a general worldwide trend in which attention to detail and a desire to produce results consistent with a high level of craftsmanship are not considered to be very important. People who espouse high standards are accused of being perfectionist, as I have on numerous occasions in my career. I always reply that I only desire excellence, not perfection. People seem to get these two concepts confused. Everyone SAYS they are committed to "high quality", but few actually seem to really care enough to do something about it.
I am not sure why this is; whether it's a decline in modern civilization in general, or fallout from the pressure to produce results quickly in a turbulent world (or both).
It's the same everywhere. You can see that a Volvo or a Jaguar are today just differently branded Ford vehicles. The trouble is that the marketing geniuses who came up with this scheme for milking extra revenue from basically the same production models failed to think that the reason Volvos and Jaguars commanded a price premium was through attention to a high level of craftsmanship. After a few years consumers will realize that the brands under Ford don't offer that craftsmanship and the brand's image and its price premium will plummet.
I can offer you an explanation for this phenomenon that is more optimistic than your view of decline in modern civilization, and this is the democratization of production and consumption. A number of technological advances (Microsoft Word among them) and globalization have nowadays brought both production and consumption of many goods to the masses. When I was young I used to salivate over the (unaffordable to me) Tektronix digital multimeters; today I can buy a DMM made in China for less than the price of a fast food meal. Of course there's a quality difference between the two instruments, but I really prefer a good-enough DMM I can buy to a perfect DMM I can't afford. Yes, regrettably Tektronix or HP, trying to complete with the low-cost Chinese manufacturers, may have also joined the race toward good-enough quality, and consequently today's HP calculators aren't what they used to be. However, given that today I can afford all these things I could only dream about in the past, so be it. The same goes for the production side. You don't have to be Hewlett-Packard or Texas Instruments to create sophisticated instruments, nor do you have to be Don Knuth or Alfred Aho to get a publishing contract with Addison-Wesley. The downside of this trend is a deluge of shoddy products, the upside the potential for more innovation.
History has shown us that in the long run democracy is a better bet than aristocracy.
I don't know — am I a hopeless romantic? A perfectionist? An idealist?
My point of view about quality is best expressed by Christopher Alexander in his brilliant book on building architecture, The Timeless Way Of Building, in which he speaks of "the quality without a name". I am sure you know this work.
Maybe my pessimism is in part due to my exposure to so much low-quality code (and design, when there actually IS a design) in my professional capacity, which I have reviewed, corrected, or otherwise had to deal with. I also lament the lack of thought that developers give to solving problems. They seem so eager to jump into coding the first half-baked idea that comes into their heads without considering the consequences. However, I believe I have been a positive influence in my current environment, and I am busy working with like-minded people to put into place automated code reviews using FlexeLint for C/C++ and PMD for Java. Later I will add other tools to provide quality metrics. (Any suggestions for such tools that you may have would be welcome). I am integrating these tools with an in-house integrated process management system, so that when a build or SCM checkin is done, the code is automatically statically analyzed; the system automatically stores the warnings that these tools produce as code review comments, which are associated with the corresponding source code files. The product manager for that code base is then sent a notification email, and will allocate developers to attend to the issues. They in turn will use a web-based system that shows the comments in context with the code, allowing the developers to see what each issue is. As they attend to each issue, the comments will eventually disappear when they fix the code and it is rescanned.
Of course, static analysis tools only provide part of the picture, but it's a lot better than nothing. As time goes by, assuming that the management don't get stupid and lay me off to "save" costs, I plan to augment these tools with (as I mentioned previously) some sort of quality metrics. Unfortunately, as you have pointed out in your book, the metrics don't really seem to count for much in absolute terms, but again, it's probably better than nothing.
Last modified: Monday, July 3, 2006 0:28 am
Unless otherwise expressly stated, all original material on this page created by Diomidis Spinellis is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.