As a software engineer, I've discovered what seems to be a common, almost universal, problem that we experience in the process of trying to deliver applications that meet the needs of our customer. And maybe this is a problem you find in other areas as well, but the problem of clearly communicating with someone that doesn't speak your language is by far the most frustrating thing that I encounter.

There are two major variations on this problem, both of which are frustrating to no end.

No Speak Computer

The most immediate communication error we experience in this field is trying to speak to someone that just doesn't get computers. Sure, they use one, probably every day, but at a high level. The same way that I use my car. I can drive my car just fine, day to day. I have a general understanding that when the one thing points to the E, I put gas in the other thing to make all the things happy. I can turn a steering wheel, I can push a brake pedal, and I can even fold the seats back. What I can't do, however, is tell you what's causing the rattling noise.

I'm sure mechanics the world over feel my pain on this. Trying to get useful, specific, and accurate information from someone not familiar with the topic at hand is hard at best, and dangerous at worst.

I've had sessions with customers lasting days at a time where we go back and forth, me trying to press and probe for information that may be useful to me, and them struggling to understand what I'm asking about. I don't blame them in the same way that I hope my mechanic doesn't blame me for not knowing about the internal workings of a combustion engine. The best we can do is muddle through and try to get by, though this could be fixed with some training. The argument can be made that since our users are using these machines for hours on end, day in and day out, for their jobs that they should be required to have basic understandings of how it works. While I don't know where every nut and bolt goes under the hood, I have a basic understanding of my car and how it operates. But good luck mandating basic computer competence in the workplace when the general feeling about the matter by management is "that's why we have you people, right?"

The flip side to the user who knows nothing and can't help you is the user who knows nothing but thinks they do. I've had customers with a fundamental misunderstanding of how the software works and what technologies are being used feed me bad information when reporting bugs or requesting new features. Which brings us to the far more insidious and destructive communication problem.

I Don't Know What I Want

It is an unfortunate adage that the customer is always right. Let's just be clear:

NO.

Customers have a need that needs to be filled, yes. They have a need that software can fill and our jobs exist to give them the product they need. The main problem is that due to a lack of understanding of the technologies used in creating software, and the frameworks upon which they are built, we're asked to build some stupid stuff and sometimes we're asked to build the wrong stuff.

Big Words

Sometimes the problem is that our customers are trying to use the same jargon we do. Which is understandable. No one wants to sound dumb. But this isn't a good idea when talking to someone about a subject where words have very specific meanings and actions have very specific consequences. Nothing in computer science just happens. Computers don't do anything we don't explicitly tell them to do. Computer's never just know what it is you want. If you're dictating what kind of software I'm to make for you, you can't be leaving out details because they're obvious to you. The programmer who isn't an expert in your specific field of business, and thus the computer, will not know that some values mean the same thing or that groupings should be made by column A instead of column B.

Design and Analysis

The most dangerous, but hardest to detect, error in communication comes from the users that have some say in how the software behaves. This may sound ideal to most managers, but in most cases, it is not. Especially when the user starts to assume they know how the software is structured.

I've seen requests for features, sometimes detailed in their description of the flow of information and behavioral components, which are completely and utterly dumb. Not that the person or group requesting the feature is dumb, but because there is a lack of understanding of how the software is structured. On more than one occasion, I've received some requests that would take inordinate amounts of time or resources or code changes to complete, and when asked what is the most important component of the feature, we find out that we could make the change for a fraction of the cost to implement the feature as designed. When asked why it was planned in such a round about way, the answer is almost invariably "We thought that would be easier for you."

Their intentions are in the right place, but rarely will someone who is not intimately familiar with the code base have more knowledge about what would be easiest for us to implement. I really feel that the whole paradigm of design by use case has quite a bit of merit, though getting use cases for everything you want to implement in a large project can be tedious.

But really, just tell us what you want the software to do, not how you think the software should do it. We're good at figuring that stuff out. That's why we get educated and train for years at school or in the workplace. Trust us.