Constant Improvements

A couple of days ago, I wrote about a customer service failure at FooBar Motors. I did not identify the company because they generally do a pretty good job of looking after their customers and that's why I keep buying cars from them and why I keep getting those cars serviced by them. The thing I was getting at is that, even when the culture is to provide great service, it's not always easy to get all the details right.

That brings me to my domain—software. We creators of software probably make more painful hoops for our customers to jump through than even the worst car dealership. And, in some ways, we have much less of an excuse: software is infinitely malleable, so we just have to fix it when it's hard to use. But we don't always know that it's hard to use. When we test it, we're kind to it and treat it the way we meant it to be treated. When it resists us, we understand it well enough to gently persuade it to go where we want. When it tells us lies, we don't feel too concerned because we understand why it lied. Besides, it's our baby and we don't like to be told that our baby is ugly, so we resort to that ever-reliable solution—denial.

And of course software is difficult to test. There are so many ways to get where you think you want to go that it's almost certain that a user will find pathways that we neither intended nor perhaps even noticed and which we certainly did not get right. Lots of people have written papers and books and given presentations about the business of software testing and I'm not going to try to push any particular approach on you today. But I think it's really important for all of us who create software to recognize that we are far from getting the testing right and that it's something that we must pay better attention to in the future.