Demonstrating Software Quality: Cut the Volvo in Half

Posted by indomitablehef | Filed under Craftsmanship, SOLID

In this excellent post: Quality Sounds Good…I Think Justin Etheredge compares the experience of buying a car and hearing about all the safety and quality features of the car to the experience of “selling” the quality features we, as developers, care about when building software. Essentially, even though I don’t really have a deep understanding of the quality features of my car, I know I want a safe, quality car, and the dealer does a good job of selling me on those features. Justin proposes that we can and should do the same for the quality features we build into our software, such as Unit testing, Dependency Injection/IOC, BDD, DDD, Single Responsibility Principle, etc., etc., etc. Even though the customers and product owners we are selling to may not fully understand the details, we can do a better job of selling them on those features than we have in the past.

Last summer, I was shopping for a new family car. Our daughter Cecilia had just been born, and wrangling the car seat in and out of my wife’s two-door Alero was proving to be quite a chore. Safety and quality were some of our primary concerns. Obviously, we were carrying around more precious cargo than we ever had before, and my wife and I both tend to keep cars for a long time. She had been driving the Alero for 7 years, and I’ve been driving my Jeep for 10.

Early in our search, I visited the local Volvo dealership to look at some used models. Predictably, the focus of their sales tactics was safety and quality. While I was there, they took me into a very interesting showroom, and gave me the rundown on the Volvo safety features. In the showroom, there were two cars sliced completely in half, right down the middle. From that cutaway view, you could see the heavy steel bars that re-enforced the car body, the crumple zones, the anti-roll stabilizers, and much more. They also had a couple of cars in there that had actually been in horrible accidents, complete with descriptions of the accident and pictures of the wreckage from the scene. At first glance, the damage to these vehicles looked horrific, but upon closer inspection, one could see that the passengers inside the vehicle had been completely protected.

Reading Justin’s post on how we can better “sell” the quality features of our software, I was reminded of my own car-shopping experience with Volvo. And I began to wonder, why can’t we as software developers do something similar? It obviously won’t be quite as easy. As Justin wrote in his post:

…if these qualities are the same in software as they are in many physical goods, then why is it so hard to sell people on quality software? Well, with the car you can put your hands on it. You can pop the hood, test drive it, kick the tires… you can feel the quality. Or at least you think you can perceive the quality. The important thing is that you cannot underestimate the emotional attachment to a physical item, and being able to see and feel the item gives a person confidence in it. The seller can throw around brand name parts, features that we probably don’t even know what they do, construction processes that make no sense to use, but in the end, it all builds up a picture in our head of quality.

So, at the very least, we can change the way we talk about our software, putting emphasis on things like Continuous Integration, Lean methods, and SOLID principles. Even though our clients and product owners won’t completely understand any more than I fully understand the safety features of my car, they can be made to understand enough to realize that these things are “good” and worth having.

Beyond that, though, can we do something more like the Volvo showroom? Can we, as a community, create the kind of examples that can take that extra step toward demonstrating the importance of adding quality features to our software? (I’m mostly wondering aloud here, hoping someone will chime in and continue the conversation.)

They’d have to be simple enough examples to be understood, but realistic enough to be relevant, and not dismissed as purely theoretical. In some cases, maybe short screencasts would be appropriate. Maybe just a community site, where we could begin to share our “brochures” (as described in Justin’s post) for the quality features in our software, and where we could piece together shared content for inclusion in our own specs/proposals/marketing materials.

What do YOU think? Is it do-able? Worth doing?