Sam says you should read this
This blog was created with the BlogFile software, written by Samuel Levy.

You can find Sam on Google + and LinkedIn.

The client is never wrong (You are)

If your client has the wrong idea about what they want, what you're delivering, or what is possible, then you're failing to do your job. There, I've said it. Their job isn't to know the technology; that's why they hired you. If they do know a bit, then it generally helps, and I'm a firm believer that if a client commissions work then they should try to understand it (at least on some level). The point is, though, that they have other things to do that don't involve knowing every line of code, the limitations of various browsers, or how much data you can (and should) push through a pipe.

Now I'm sure that I'll be called out here by people claiming that there are plenty of belligerent, combative, wilfully ignorant clients out there. I've encountered a few myself who simply refused to believe a word that I told them. I'll tell you something, though. They are very few, and very far between. The majority of clients just require gentle handling and a little education about their systems. They don't want to be in the dark, and they don't want to fight you to get things done, but they don't know how to relate to what you do.

When I started working for actual clients, I would listen to what they asked for, and build it, no matter how illogical it seemed. If I couldn't figure out why they would want something done in a particular way, I would either rant at my co-workers about unrealistic expectations, or build it in my own way and just tell them I did it theirs.

I would have been a shit to work with then. For anyone who had the misfortune to work with me when I was finding my feet; I'm really, really, sorry.

One of the most important parts of my job is communication. I'm still not great with it (I have a habit of being silent when working on things until I need more information, or until I'm done). Almost every dispute in my career could have been resolved if I had just talked to the client, and asked what they wanted.

Once again, I'm sure I'll receive the virtual scoffs of many other programmers. "Clients don't know what they want when you ask! That's the problem! All they can do is tell you that what you did is wrong!"

This is where being a professional comes into play. The client might not know what they want, but they don't know what you think they want, either. If you don't tell them what you're building, then they won't know until you've built it. By then, it's too late - you've already wasted their time and yours building something that they don't want. You should be communicating with your client during the design phase, through the build phase, through the testing, and through the hand-over. They are giving you their money in the hope that you will build what they want, and if you don't bother to find out what they actually want, then they won't want to give you any more money. If your client doesn't want to pay you any more, then you're not going to flourish for long.

Communication with the client should be early and plentiful - you don't have to pester them with every single detail, but you have to be clear on features that they've mentioned, features that you've offered, and any problems that may derail the project.

If the client has asked for something to be done in one way, and it doesn't make sense to you, ask them why. Don't just ask them why either, but offer them alternatives. If another way would work just as well, then they'd be happy to know about it - especially if it saves them time and money in the future. If there's some really obscure domain-specific knowledge built into the business logic, which contains an edge-case that only their business will ever encounter, then you need to know this before you ignore their spec. You might still be able to come up with a better solution, but you won't know what is important until you ask them.

If something is impractical or impossible, then you have to tell your client. Maybe you can come up with a more practical solution, or maybe it's impractical because that's how the business (or even some government regulation) says it has to run.

Part of your job is to educate your client about how their system works. The first step to doing this is often to educate them as to why they should care. This isn't always easy, but it's worth it. Once your client starts to understand, even in broad terms, what the system does, then they will be less likely to get upset about what it doesn't do. If you don't tell them what you're building, then it doesn't matter how good your system is - it's not the system that thought they were getting.

Finally, you have to remember that while the code is your business, your clients' businesses will be something else entirely. Some battles you have to lose (or not even fight) because as important as a feature or an idea may be to you, there's nothing but financial loss in it for the client. Be mindful that their business is what keeps your business running. If you're going to spend 10 or 20 hours working on a feature that will never get used, ask your client about it first.

Just remember this the next time that you're working on a bloated feature that you think won't work: The client is never wrong; You've just failed to communicate.

Comments have been locked for this post.

this stupid blog post just makes it harder for people in the industry than it already was. After this clients are going to try and bully their employers more than it already happens.

Samuel Levy

If you're getting bullied by a client, you can drop them and find other clients. If you're getting 'bullied' by many clients, then maybe you're the problem.

On average, freelancers will charge massive amounts for an hour of their time, then spend many hours working on a problem. You should be providing more service than just code for that money, and if you aren't then you are the one making it harder for other people in the industry.

I have had a number of clients with me who have struggled with previous freelancers because the other guys didn't communicate. The clients never fully realised what the problem was until they worked with me. I had to break through all their prejudices against freelancers that were built up from multiple bad experiences that were simply not their fault.

If your client doesn't want to pay you, then you've failed to communicate the terms of your agreement. If they're trying to dud you, then you have to have protections in place (in terms of contracts, etc.), and you have to communicate with them the fact that they're in violation of those terms. If they're still trying to dud you, then you should communicate with your lawyer, who can communicate with your client. If you just say "The client is wrong! What a horrible client!", and leave it at that, then you're not going to make anything any better.


1st poster is an absolute idiot.

After a few years of experience I think the most important part of building a new system for a customer is NOT the coding itself but everything else. The article is right in every aspect and it was a good read as well. It doesn't matter for the customer if you can code excellent in 5 languages and whatnot. What matters to them is that you understand their problem and good in other domains as well.
If you just code what he says, you are just a geek. If you understand the pitfalls of having and dealing with a company, making financial decisions, have a knowledge of accounting and law related issues, you'll more likely to be percieved as an important asset and you will be remembered and receive more work.

So the bottom line is: Know other domains of life, not just programming. If you focus on this, selling your skills will be much more simple.