Clif Notes: We Are Not In Control (But We Can Be In Charge)

When it comes to application development, we are no longer in control. Frankly, we never really were. But today it is almost impossible to continue the illusion. It used to be that we — the information services professionals — did everything for the users. (Some would say "to" rather than "for.") After all, the way we saw it was that users were ignorant. Not only did they not know what they wanted, but they were not versed enough in the mysteries of Data Processing to even know what they needed. But we, the priests, knew what they needed and how best to deliver it. And if the applications we delivered did not match the way they worked or the procedures they used, well, they were doing it wrong. (Sounds a bit like Steve Jobs initial reaction to the antenna problems on the iPhone 4 doesn't it?) Forget the fact that few of us in Data Processing had ever been a shipping clerk, an accountant, or a warehouse manager; somehow we thought that we could design applications that would bring order to the chaos. Just a little bit of hubris, don't you think?

To be fair, not all computer professionals had such a delusion. Over the years there have been attempts to involve the users in the definition and design of software applications. One of the most notable of these was the Prototyping movement. The fundamental idea was that the stereotypical user would say, "I don't know what I want, but I will know it when I see it." So the application programmer would cobble together some minimally functional code to present a screen layout or a report mockup for the users to look at. After several rounds of, "Yes, but…," we (the application developers) would have a good definition of what the users thought they needed and how they wanted it to work. At that point it was SMOP — Small Matter Of Programming.

It sounded good, and it was definitely an improvement over designing and developing applications totally in a vacuum. But it still fell short. For one thing, at that time users were not fully aware of what computers could do or how they did it. They didn't really know enough to state how they wanted something to work; they tended to simply concentrate on screen and report layouts. On top of that, programmers and managers had a tendency to consider the time taken cobbling together minimal code during prototyping as "wasted" unless that actual code became the base of the finished solution. So what you ended up with was a software application grown from junk code that kind-of sort-of, not-quite did what the users thought they wanted, but didn't understand.

And then our world changed.

Enter the Apple II, the IBM PC, and the personal computer revolution that followed. It used to be that the shipping clerk had no idea how computers worked or what they could do. Now he goes home at night and probably spends at least part of the evening on the family computer surfing the Internet, ordering things from retail websites, or using accounting software to pay his bills and prepare his income taxes. Today, he knows very well what a computer can do and wonders why that obsolete piece of junk he's forced to use at work doesn't do the same thing.

It used to be that users didn't even know the terminology. Try to explain to somebody what a megabyte was and they would stare at you like you had two heads, wondering why the computer guy had suddenly developed such an interest in dentistry. Start talking about relational databases, and they would politely mutter something about not really being interested in genealogy and walk off. Today, maybe only by osmosis from their computer-literate children, such terminology no longer causes their eyes to glaze over. (For that, we had to invent new terminology like "object-oriented programming" and "polymorphism.")

So now our users know exactly what they want. They know how they want it to work. They are not easily cowed by elaborate terminology. And their expectation of the applications you provide are determined, in large part, by their experiences with other providers applications. They want access to information (not just data) anywhere any time. And they want it now. If your applications do not meet their expectations, they will simply throw yours out and get one that will.

Also, the modern user is not going to wait for the Information Systems department to do a three-month requirements analysis and application design, followed by six months or more of application development. By the time you deliver that, there is a very good chance that the situation has changed and they have found another solution on their own.

In other words, the Users are in control, not us.

So where does this leave us? Out in the cold? I don't think so. Just because the users are in control does not mean that they are independent. With the exception of spreadsheets — and in a few cases Access or FileMaker databases — most users are still not able to develop their own applications, even when they know exactly what it is they want. And most of them don't want to. After all, if somebody wanted to spend their life developing applications, then "they" would be "us." But our role has definitely changed. And while we are not in control, we do need to take charge. So how do we go about this?

First and foremost, we need to make communication with users one of our primary responsibilities. I know this goes against the grain of a lot of computer people, but think about it. If you are not talking to the users, how do you know what their expectations are? And we've already talked about what's likely to happen if you do not meet their expectations.

Then, we need to become better at producing accurate, high quality solutions quickly. Agile methodologies is a good place to start. While the modern user will not sit still for nine to ten months until a complete application is put in front of them, they will stick with you for a few weeks until a partial solution that relieves their biggest pain point is delivered. Then another few weeks until the next piece is delivered, and so forth. That is especially true if they are the ones setting the priorities of what gets done first, then next, then next. It might still take ten months before the solution is complete. Of course, there is always the possibility that after six or eight months they might say, "You know, this is good enough for now. Another pressing problem has come up that we would like your help with. Let's work on that instead."

And finally, let's stop reacting to change. Let's start driving the change. If we start making communication with users one of our main objectives, given our backgrounds and our MultiValue tools, we are certain to spot opportunities to use technology to improve a process, increase productivity, or create another competitive advantage.

So recognize that your users are actually your customers, and take charge of finding out what they want as well as need. And quickly deliver, deliver, deliver.

Besides, being in charge of a successful solution is a lot more fun than being in control of an unused solution that failed.

Clif Oliver

View more articles

Featured:

Mar/Apr 2012

menu
menu