Quality Sounds Good…I Think.

Writing

Thanks to recent legislation passed by the United States Congress, many people in American are trading in their old run-down gas guzzling cars for much more fuel efficient vehicles. My wife’s parents are taking advantage of this offer and they recently traded in an older Nissan car for a lean-mean fuel sipping vehicle. They really wanted us to come see the new car when we were over there Sunday evening, but unfortunately they were unable to take the vehicle home that evening because the dealership needed to "detail it". Not sure what you need to detail on a new car, but that is probably code for "we just got this one on the lot and had yet to put our dealership’s logo on it".

But anyways, after we got over to their house we talked with them for a while and then my wife’s mother brought out the brochure for the new vehicle that they were purchasing. They started going through the brochure showing us all of the cool little touches and features that the car they were getting contained. I was starting to get a little jealous! I found myself wanting things like a push button start and doors that unlock as I got near them. After going through the brochure, I was thinking, "Man, I want one of these!" But at the same time, this car was not one that I would ever be interested in or even consider purchasing, but this brochure just made the car seem soooooo sexy.

After we had gone through this brochure, and my want for a new vehicle had been rekindled, I started thinking about a book that my former boss and friend over at BV Software had asked me to read. It was a book by Seth Godin called "Free Prize Inside". In this book, Seth Godin explains why people will buy products for reasons which seem to have almost nothing to do with the qualities they should be looking for. Like the title of the book says, people often buy and item for the "free prize inside". I didn’t want the car that I was looking at, I just wanted a push button start and Bluetooth. Why? Because it is a gimmick, they know how to sell it, they just throw feature after feature at you and before you know it, you want all of them! The interesting thing is, that they are masters of turning mundane items, like an ignition, into something that is a desirable feature.

This got me really thinking about a problem that I have been mulling over in my head for a few months now. As a consultant, I often have this feeling that the tools and skills that I am interested in aren’t very marketable. Certainly not marketable like a person who is an expert in a product. I am very interested in languages, IoC containers, design patterns, simple libraries, productivity tools, etc… Basically I am interested in building the lightest, leanest, well structured, and maintainable software that I can, but unfortunately that doesn’t look very good on a brochure. Telling someone that you write "maintainable" software is going to be a hard sell.

But why is that? I think it all goes back to the fact that people who aren’t developers can’t really picture or understand software quality in ways that they can relate to. For example, if you started talking to them about an automobile and you told them that it was reliable, well built, and maintainable then they would say "sure, that sounds great, of course I want a quality reliable car." And when you mention reliability to a person in the context of a car, then they can say in their head "okay, this car isn’t going to break and leave me stranded on the side of the road." And when you say "well built" they envision quality parts, that again, won’t break and leave you stranded. When you say maintainable, then they assume that the car can be easily serviced by technicians in an inexpensive and quick manner.

Now, I don’t know about you, but when I think about how people perceive quality in a physical item such as a car, I can’t help but see that the parallels between quality in software and the quality in the car are far more than superficial. Reliability is all about the software running without issues, "well built" is all about having software which is built to a particular level of quality, and maintainable means that it isn’t going to take 5 years to make changes to it.

So 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.

Now again, when I think about how a person approaches and quantifies quality in a physical item, it gets my brain churning on how we could turn this to our advantage. Like I said above, people often react positively to features that they don’t quite understand or don’t really need, and we have an infinite list of things that we put into software that the layman doesn’t really quite get. As an example, if I told someone that a car had "double wishbone suspension" most people would have no clue what that means, but because of the fact that I called it out, they now associate that with quality. Now I can’t just make anything up, because if they do ask about it, you better be able to at least give them an idea of what it is.

So what can we do when selling our software to take a note from the automobile manufacturers? Well, we need to catalog features of our software that we put into it, even if they layman might not understand it. We need to sell our process, our tools, and our methods of quality. When someone looks at a piece of software and is asked to describe its features, we often describe what the software does. The features that the client asked for, such as "it allows the user to update a subscribers password." But that is like the car salesman telling you that "you can drive really fast in this car." Of course you know that you can drive really fast in that car, that is why you wanted that car! You just want to know the really important stuff, like whether or not it has headlights that turn when you go around corners. 🙂

So again, what can we describe in our software which makes it seem more desirable? Do you use an ORM? Check. Are you writing tons of unit tests? Check. Dependency Injection? Check. Agile development methodologies? Check. Continuous Integration? Check. The list can continue on and on. I would name libraries, tools, methodologies, approaches, etc… Just be prepared to explain what they are, and why they give you an advantage.

Now I don’t want anyone to be dishonest, what I want is for you to build quality software but then let people know what you do to write quality software, even if they don’t understand. What they will understand is that you care enough about your software in order to use that tool or technique, and you let then know about it and then told them that it would make their software cheaper and faster. And you know what, it more than likely will. Just because we are software developers doesn’t mean that we shouldn’t take the time to sell ourselves.

Loved the article? Hated it? Didn’t even read it?

We’d love to hear from you.

Reach Out

Comments (10)

  1. This post really hit home. It’s one thing for us to understand why these principlespractices are important for development, but it’s a whole other challenge to "sell" the need to our clients (or even bosses). Great post Justin!!

  2. So, things like ORM, unit tests, etc. seem equivalent to double wishbone suspension or ABS brakes. They are attributes that signify quality.

    What’s equivalent to push-button ignition or adaptive cornering headlights? These are attributes that are sexy and feel like quality but really have little impact on the core functionality of the system.

  3. Justin,

    It’s all about features and benefits. What the product does or has and what the purchaser gets out of it.

    Well built, reliable software means very little downtime for the client’s customers.

    A client’s business process changes over time. So will their software. "Maintainable" means lower costs when the software DOES need to be changed.

    Agile development and continuous integration means that the client gets working software sooner and with fewer bugs.

    When I was in retail we used to make a game out of it. During slow periods someone would mention a feature of a product we sold and we all had to come up with benefits that feature afforded the customer.

    A good (and timely) post!

  4. @Chris Awesome, great post! I think you are right, a good next step would be for people to setup some kind of shared repository for how to sell some of this stuff. The only problem is that people are often very tight lipped about their sales process.

Leave a comment

Leave a Reply

Your email address will not be published.

More Insights

View All