Do developers Create bad clients?

Indecision
Just like riding a horse, when you're working with a client, one person is typically going to be directing the process. As a professional developer, that person should be you. This isn't about talking the most, telling the client what to do or ignoring their wisdom about their business (which they probably know much better than you). It isn't about putting them down when they say stupid things about computers or programming and it isn't about believing that you are somehow better than them just because you can hack together a blog in Perl in less than 15 lines of indecipherable code.

It IS about knowing the overall process of turning vague wishes into meaningful requirements into clear and complete specifications into working code. It is allowing the client to talk, but gently steering them in the right direction. It is knowing that while they may know their business, you know how to help them to turn their vision into a working application. It is about understanding the client is often wrong, but knowing when they are wrong and how to let them figure that out elegantly and comfortably.

Humans, like horses, can smell fear, indecision, and weakness. Imagine that you are on a small boat. The seas start to get a little choppy and then the waves start to come over the sides of the boat. In one world imagine a captain looking you straight in the eyes, explaining that this is normal and that it'd take waves three times this size to affect the boat. He shows you how the deck is designed to let the water flow out and explains this design is because this happens to boats all the time. He suggests you sit down and enjoy the adventure and that you'll be back in port in time for lunch, using an even, confident voice.

Now imagine the captain looks at you quickly before looking down and away. There is a slight sheen of sweat on his face and he nervously replies with a wavering voice that "it'll be fine". Or imagine a captain that just arrogantly stares at you, tells you that you know nothing about boats and to sit down and shut up because he's on the phone to his wife.

With a nervous captain, the fear is contagious. You're going to be second guessing their steering and looking out the life jackets. With the arrogant captain, you may know intellectually that it's going to be OK (otherwise they wouldn't be busy chatting to their wife about how the dog is doing), but you probably don't feel reassured and you're unlikely to take this boat again if you have a choice. The first captain had to spend a little more time explaining things to you, but by doing so, both of you have a better experience and you'll definitely feel safe sailing with them in the future.

One of the biggest challenges with allowing new developers client contact is that they seldom have the necessary balance of confidence and humility to steer the clients towards the right solution. And once a client is uncomfortable with a developer, they'll become a "difficult" client because they'll want to double check everything they do and to question all of the assumptions they have made.

Mishandled Errors
We all make "mistakes" when programming. Even great developers make simple mistakes or the client will come up with exception conditions that weren't considered when developing the code. Most clients understand that bugs are a normal part of developing code (and those that don't need to have it explained to them ASAP). However, when there are too many bugs or they aren't handled in a confident but professional way, if you're not careful, the client goes from fundamentally trusting your competence to fundamentally assuming that you are incompetent and that change in their beliefs will have a huge impact on how much hand holding, reassuring and support they'll require during the development process.

Badly Positioned Boundaries
There need to be boundaries in any relationship - including between a developer and their client. If you don't have any boundaries, pretty soon you'll be over at their office fixing their email software or removing viruses from their hard drive. If you have too many, unless the client backs down (possibly ending up resentful), you'll probably end up in long disputes about what exactly is or isn't included in the agreement you signed as they feel you're just trying to do the minimum possible to get their check.

It's All About Trust
I broke this down into three examples, but in the end it is all about the level of trust between the client and the developer. When the client doesn't trust the developer, they are much more likely to exhibit "difficult client syndrome".

What do you think? Clearly there are some clients that are just plain difficult - whether they trust you or not. Can you think back to any times when you've created a difficult client? Anything you could have done differently to handle the situation?

Input appreciated!