This type of customer mentality really drives me nuts. I worked at a fast food joint for 4 years while I worked my way through college so I have seen, first hand, the ugly side of this way of thinking. This mind set gives the customer a puffed up sense of their worth. Sure it is their money that pays for salary and keeps you in business but it does not justify childish tantrums and harsh name calling or cursing because their coffee is wrong (even though you made it exactly as they ordered).

Now that I am on the other side I catch myself displaying some of these tendancies from time to time. Mind you, these behaviors only play out in my head, I am a nice guy after all. I wouldn’t ruin someone’s day just because I have to wait an extra 30 seconds while they remake the coffee.

Luckily for me, I have a beautiful wife to keep me inline. She worked in retail for nearly 6 years before deciding to be a stay at home mom after our son was born. She is always quick to point these things out when I start to complain to her about my bad trip to the grocery store.

What does this have to do with software?

Well, nothing. Also EVERYTHING! This thinking does not stop when a client walks into your office for consultation or for a scheduled development meeting. Yes, the client needs to be invlolved regularly through out the course of a project. They are the experts in their business (domain), afterall.

Let me momentarily digress to say that I agree that the customer should always be treated as the the King. They should be listened to and given all the attention necessary to keep them a happy and loyal customer. Their inappropraite actions, however, should not be tolerated.

Back to the point of the article that I am trying to get to. Applying to development, the client should have the final word on features and other design considerations. They are after all going to the the end user and are the ones paying for it in the first place.

You mean do everything they say?

Of course not! Your client doesn’t know anything about software engineering. Huh? What? How do you treat the client as if they are right and intentionally ignore their stupid ideas? Well, you don’t. I mean, you don’t ignore, seemingly, stupid ideas, you address them.

Your client is the expert in their business but you are the expert in your business. You need to find a middle ground to provide what is best to help the client acheive their goals while maintaining good design for your project.

You will first need to explain to the client why you think this is a bad idea. They will likely repeat why they think it is a good idea. Come prepared with a few senarios that highlight why it is a bad idea. You never know maybe you misunderstood and the client can show you why it really is a good idea and you can refactor your code to accomodate this feature in a sound way. Visual aids and narritive dialog go a long way in resolving misconceptions on either side.

This is why I think it is critical that the client be involved in the various stages of a project. They will help you catch mistakes or errors in implementation or they may even think of new or improved features.

Imagine if the first thing the client gets to touch is the finished project. “Why does it do this? I thought we said it has to do that” will leave both parties frustrated with the project even if you did implement it perfectly to specifications. Then you will get to experience those tantrums I am talking about.