I was recently asked, “What does quality mean to an Access developer?” The person who was asking me was trying to find what areas he should concentratehis development efforts in. Another way of putting this would be, “What does a high-quality Access application look like?” After some thought, I decided that I was being asked the wrong question. I think the right question is, “What does quality mean to an Access user?” As with user interface design, I suspect that no one cares what you think about the quality of the application that you deliver. In the end, it’s only the opinion of your users (or the person who pays your bill) that matters.
There are some obvious conclusions to be drawn from reformulating the question. As I’ve suggested in earlier columns and articles, your user interface is indistinguishable from your application, so building a user interface that your users like is a critical part of creating a quality application. Robustness and reliability are also obviously critical. No one will regard an application that blows up on a regular (or even irregular) basis as a quality product. But after that, the criteria for a quality application get fuzzy.
For instance, you might assume that an application that runs very slowly wouldn’t be regarded as a quality application. Interestingly enough, that’s not always true. Users discount speed when rated against “work done.” If users believe that the program is “doing a lot,” they don’t object to slower response times. Users don’t mind an application that runs slowly on an infrequent basis and at easily predictable times (for instance, if the month-end processing is known to take two hours, this isn’t as critical as having the application randomly slow down). Users also discount speed based on the type of application: Users accept slower response times from Web applications because they expect anything that runs in a browser to run slowly.
So what can you do? I don’t want to sound cynical, but: If you don’t manage your users’ expectations on application quality, then—no matter what you do—you won’t deliver a quality product. So you need to establish in your users’ minds what success will look like.
One technique is to get your users involved in the process as early and as often as possible. There are two reasons for this. The first, and most obvious, is that early involvement lets your users tell you what they regard as a quality product. With that information you can target your efforts toward delivering an application that meets those goals. The second reason is summed up in the old adage that “No one has ugly children” (more crudely put as “The chef likes the stew better when he’s peed in the pot himself”). An application that users feel they’ve had input to, that they feel is (in some sense) theirs, will be regarded as being better than an application that’s forced on them. It seems to me that many developers inflict systems on users rather than implement applications for users.
Another technique is to explicitly establish expectations at the start of the project. My approach is to tell users that we won’t deliver for years (if at all), that the application won’t do much of anything when it’s delivered, and that what functionality is implemented will be very buggy. I recognize that this isn’t an approach everyone is willing to adopt. However, most developers adopt the exact opposite approach: Set very aggressive schedules, promise the moon, and commit to completely bug-free software. While these are admirable goals, it’s an unusual developer who can do all three on the same project.
A third technique is to take control of writing the user manual. As part of the user interface, the user manual provides a mechanism for you to point out what the important features of the application are. You want your application to be judged on the parts that you spent time on—not on some infrequently used utility form that was put together in an afternoon because, quite frankly, it wasn’t worth any more time than that.
There are other tools that you can use to help set user expectations appropriately. But what about all the criteria that we, as developers, use to rate our work? Clean code, good object design, fully normalized database designs, timely delivery, and so on. These are all admirable goals and would be very useful if your work was being judged by other programmers. However, all of these criteria are really just a means to an end and not an end in themselves. That end is your ability to make enhancements to your application and to find and fix bugs in it (should there be any). Those goals are only relevant if your users have enough faith in the quality of your product to have you back again.
And what does quality mean to an editor for Smart Access? That’s easy: giving you the information that you can use to solve your problems.