In response to my last column, reader TimR posted some good points as to why developers have difficulty producing software that users are happy with. I’ll address two of them in this article: that users have difficulty specifying what they really want, and that users have unrealistic ideas about what computers can do. Both of these statements are true, but it doesn’t matter. It’s your job and mine to produce good software despite them.
Consider the case of a primary care physician. It is not the patient’s job to say, “Gosh, I think I need a laparoscopic cholecystectomy” (minimally invasive gall bladder removal). The patient says, “Ow, my belly hurts.” It is the doctor’s job to diagnose the problem by asking questions (“Show me exactly where it hurts. Is the pain dull or sharp? Throbbing or steady? After eating or all the time? When you go like this? Then stop going like this, doofus.”). The doctor may also manually examine the patient (“Turn your head and cough”), or order tests such as X-rays. Further, it is the doctor’s job to explain his diagnosis and proposed solution to the medically ignorant patient (“See these white things on this X-ray? They’re gallstones, and that’s what’s causing your pain. No, it’s not your appendix, that’d be down here on the right”). And the doctor frequently has to deal with the patient’s unrealistic expectations of treatment options (“Sorry, but what you read on the Internet is wrong. Ultrasound shattering works well on kidney stones because they’re brittle, but gallstones are softer so it doesn’t work for them. So unless you can live with this pain, we have to stick a knife in you. Actually three of them, but they’re small, and you’ll be sleeping.”)
The software architect is in a similar position. It’s not the customer’s job to design a solution. It is the customer’s job to describe the business problem that he needs to have solved. For example, it’s reasonable to expect the customer to be able to say, “My family runs a Vietnamese restaurant. My father the chef doesn’t speak much English, and bilingual Vietnamese waiters are hard to come by here in Omaha, Nebraska. Somehow I have to take the orders in English from the diners and get them to the chef in Vietnamese.” (This is the actual case solved by Tu Nguyen in winning Microsoft’s Imagine Cup contest in 2003, which I helped judge. He used it as a catalyst to start his own business, see www.eddsvault.com.). Like the physician, it is the architect’s job to ask questions that further define the problem and narrow its scope. “How many waiters are usually on duty? Usually one, sometimes two? A simple data entry terminal might work. Five? Now they’ll have to queue for the terminal, that won’t work. How often do orders get mixed up, and how much does it cost you when that happens? That much, eh? Maybe your payback period is shorter than you thought, would that increase the initial budget? Are there any other chefs, and what languages do they speak?” And so on, through a number of iterations, until a solution emerges (“Let’s give each waiter a Pocket PC on a wireless network, have a simple translation table on the server and a printer in the kitchen”) And again like the physician, the software architect needs to deal with the customer’s unrealistic expectations (“No, sorry, the Pocket PC batteries won’t last for a whole evening because the network draws too much power. If you don’t want to buy spare Pocket PCs, then you need to at least have spare batteries sitting on a charger. Until someone comes up with wireless power, that’s the best we can do.”)
Most people think of medicine and software development as primarily technical disciplines. And indeed, they both contain a large technical component. A doctor has to know that there’s this thing called a gall bladder that’s useful but sometimes causes trouble; a software architect needs to know that there’s this thing called Wi-Fi that’s useful but sometimes causes trouble. That technical knowledge base of both professions is necessary but not sufficient. Proper practice of both professions require expertise in dealing with human beings, which neither profession performs to anywhere near the quality that they need to.
The medical profession is starting to address this shortcoming in its training curricula, through such avenues as role playing exercises. The software industry needs to move in that same direction.
Our customers are human. And they’re going to stay human for the foreseeable future. Instead of saying, “We can’t do a good job because our customers are human,” we need to figure out ways of dealing with humans in the software business. Is that hard to do? Of course it’s hard. But whenever a developer or student says to me that something is too hard, I always reply, “Isn’t that another way of saying that you’re not smart enough? That can’t possibly be so, can it?” That usually ends the conversation. And I’ll let it end this posting as well.
