One of the biggest differences between people who succeed and people who flounder is that those who succeed are constantly questioning and examining. They are continually polling others for advice, and while they don't always take it, they do keep the array of views in mind and keep a running scorecard.
Early programmers, by contrast, were often self-sufficient loners who, in the recesses of their parents' garage, were reinventing the world on a screen. Even today, end users often find it hard to avoid a feeling that computer programs are written for those who write them rather than those who are intended to use them. We have all been frustrated by at least some of the following:
♦ Search lists that don't return you to base
♦ Word processors that have no concept of leading or settings
♦ Graphic programs that produce weird textures but not wood grains, concrete, knits, or glass
♦ Financial programs that cannot multiply
♦ Help systems that don't employ the conventional terms and offer little real help
Developers usually get themselves into such positions because they never consult the people whom the program is supposed to assist before they frame their specifications. The classic defense to such complaints is a) "There's nothing wrong with my program," b) "I didn't know anybody to ask," or c) "I didn't want my idea to be swiped." These really boil down to the fact that the developers didn't know or bother to learn about their market. If you don't know any potential users or buyers, it is all the more essential that you find some.
Use your instinct. Take some users into your confidence a little or find a way of questioning them obliquely. This may call for a little ingenuity. Most of the time people will be delighted to help you.
If you are developing a program for supermarket checkouts, work with their cashiers for a day. Ask them to tell you their greatest problems and what innovation could help them most. Then repeat the process with the store manager and head office. People empathize with products all the more when they have made a contribution. Successful software is always a team effort.
Was this article helpful?