As information technologists, we focus on what the software we write needs to do when we write it. When we finally release it to the user, we’re pretty sure we are familiar with every aspect of it. But, even if we think we wrote it to the user’s specification, there are surprises, some of which remind us of the cognitive tests we took in school, where we are to choose the one that is different, among seemingly unrelated objects.

There’s an old saying that goes, “I’m sure you think you understood what I said, but I’m equally certain that what you heard is not what I meant.” This goes both ways, when dealing with users. Users describe their problem in their own vocabulary, and have a pretty good idea of what they want to see, but usually not a clear idea of how to make the computer do that, which is why they hire us. We have a pretty good idea how to organize data efficiently in the computer and present it, but often, we miss the subtle meanings in what the user asked, if it doesn’t immediately translate into a neat structure.

Often a user will say, “This item, this item, and that item are special. They need to be treated differently from the rest.” So, we dutifully list those items as exceptions and program for them, probably in a lookup table. Later, the user comes back and says, “The special handling isn’t working.”

We look over the requirements, review the code, can’t find anything wrong, so we ask, “Which ones aren’t working?” The user then points to a new piece of data, one we haven’t coded for. Slowly, it dawns on us that the data items the user listed as special aren’t in themselves uniquely special, but belong to a special classification, that perhaps isn’t immediately obvious from the original list. Whether the association is even recognizable may require some in-depth understanding of the user’s knowledge domain, so now we are faced with the problem of fixing the data each time new data is added, or whether we fix the program to recognize the pattern.

But, if we find a pattern, we need to check with the user to find out if that truly is a distinguishing characteristic, or just coincidence. It could be that the user hasn’t noticed that the naming for his special category happens to follow a convention, and the next one might just have a different twist on it, or the pattern you deduced may not be unique to the set of items the user is thinking about. Normally, if data items are to be grouped, there should be a field in the attributes to identify membership in a group, or a separate table if an item can be a member of several groups. However, when imported data must be classified automatically, it is important to clearly identify a unique recognizer pattern, and make sure the user understands the need to be consistent.