Ten things that should be common sense to the developer-client relationship... but somehow aren't.

Working for a vendor as a developer has opened my eyes to a few things where the client-developer relationship is concerned. Some of these things are mostly common sense... or so I thought. Having been employed by three different vendors, I've seen developers (myself included) totally miss some of these. And the results are often not pretty.

Keep client data safe
from misuse - especially from
you!

1. Respect Client data

This one is a biggie. As a vendor, especially when you're hosting client data on your own servers, you may have access to client data such as the client's customer database. And it doesn't take a genius to figure out that if the confidentiality of this data was ever compromised, things could get sticky. Both professionally and legally.

I've seen developers use one client's data and export it to the staging database of another client, for testing purposes. Even assuming that the original client doesn't find out, what about the client who finds someone else's data on his staging server? Can someone say "crisis of confidence"? If you, as a developer, could handle someone else's data in such a cavalier fashion, why should you be any less careful with my data?

And yes, the last developer I know who did this, lost his job. Deservedly so.

What the client wants is not always
legal or good for him.

2. The Client is always sometimes right

Clients, as a rule, are not just paying you to do the grunt work of building their web portal. They're also paying for a certain amount of expertise, and this should come in the form of recommendations and critique, even if it contradicts what the client wants. Especially if what the client wants is legally questionable (complying would bring you in conflict with existing laws), technologically unsound (complying would crash your server or introduce unreasonably long lag times), or contravenes best practices (such as cross-browser compatibility, searchability or security). The client deserves to be advised of such, and it is your duty, indeed the bare minimum, to do so.

So don't use "customer is always right" as an excuse, and blindly follow what's written in the requirements.

That said...

Know when to shut
the hell up, honey.

3. The Client is usually right

Yes, the client is paying for your expertise. Yes, it's your duty to advise.

And yes, you should totally know when to shut the hell up and do the work.

Sometimes you may not agree with the client. Perhaps you don't think the sidebar text should be in the sidebar. Perhaps you think the font is all wrong. Perhaps you don't agree with certain color choices. Yes, you know more about websites than your client. But it's his money. Your ego needs to take a back seat there.

By all means, make your recommendations. But if the client has noted your objections and dismissed them, for goodness sake, let it stop there and get the job done. The client wants what he wants, and after you've advised him to the contrary, it's his responsibility from thereon. This is not about you.

I once had to work with just such a developer. Her client came with a request and as she was busy, the request was forwarded to me. I performed the necessary changes and because things got really busy after that point, forgot to respond (yes, contravening Point 6 below). The client called me back later to check, and I informed her that yes, the changes were done and apologized for not having informed her earlier. To my surprise, she expressed an amount of gratitude I considered disproportionate to the amount of work I had done (basically one page with two buttons and some text).

Apparently, when the client had asked the other developer to do this originally, the other developer had argued vehemently against the chosen color scheme and page, and this had gone on for over a workday. That I had carried out the request without fuss, in the space of half an hour, seemed like a godsend.

In a nutshell, all I really want to say is - that's company time you're using. Don't waste it on things that are out of your jurisdiction.

Customer checklist is your priority.

4. Client KPIs come first

Somewhat related to the previous point, value-add is a good thing. But it's even better to understand your priorities. There are some things the client doesn't ask for which may or may not be implied. Things such as cross-browser compatibility, W3C compliancy, and so on. And having those things is a good thing.

But the Client's explicitly-stated KPIs should come first.

The client doesn't care about things he never asked for. You could include fifty little freebies that make his system sing like a bird; but if there's even one item on his list that he wanted (and paid for), but isn't there, the project isn't done. Again, that's company time you're using. Make it count.

Email FTW!

5. Verbal doesn't count

Sometimes the Client thinks aloud during a conversation. Sometimes, during a meeting, some stuff gets thrown about. But all this means jacksquat if it's not documented. It's very easy, and dare I say, very convenient, to forget stuff if there's no proof it was ever said, other than a fuzzy metric such as human memory.

Draft an email after each communication, and send it to the person you communicated with, asking for clarification and confirmation on the points made. CC all relevant parties.

That way, if something goes south in the process of getting things done, at least it can be traced. The entire conversation wasn't just a figment of your imagination.

Which also brings us to...

Talk, dammit.

6. Communicate often

When a client sends you an email, the reasonable assumption is that he would like a response today. Sometimes you need time to properly formulate your response. That's perfectly acceptable, and one of the advantages of being able to communicate via written medium. A good limit to set would be to reply all his emails between two to four hours later, if not right away.

Better still, call, and then confirm your conversation via email. (see Point 5)

Some clients may jump to the wrong (or right?) conclusion that you don't care, if you don't respond within a certain time-frame. And unless you're some kind of masochist, you do not want to give that impression.

There was this vendor whom I joined years back. One of the developers, a Burmese, had passed me a client project that I could cut my teeth on. During the next couple weeks, we took turns attending to the client. Midway through the third week, the client emailed my boss to ask if I could be put solely in charge of the project from now on, as I seemed to understand their requirements better. And everybody knows that when the boss gets an email like that, it's pretty damning.

Bear in mind that this was only my third week on the job. Prior to that, I hadn't touched any C# or ASP.NET. Where this was concerned, my Burmese colleague was unquestionably the better programmer. What was the difference?

No prizes for guessing: communication.

To be fair, English wasn't the guy's first language. But he had a bad habit of not answering emails promptly enough, and not reading the emails carefully before working on the requirements, and not clarifying his doubts. I didn't have that problem. It wasn't that I was a particularly good communicator, it was more that my colleague was horrendous at it.

Remind you of anyone?

7. You're not paid to work...

...you're paid to get work done. Many developers can't tell the difference, and that's their undoing.

The client (and by extension, your boss) doesn't care that you spent all night slaving on his shopping cart, as long as it's delivered by 9am in the morning as stated in the project timeline. He doesn't care that you missed your mother's birthday because you had to fix the security bug in his inventory management system. He doesn't care, and he shouldn't care.

So don't imagine that if you're seen staying back late in the office or working on weekends, that it gives you a free pass. You're given eight to nine hours a day (officially at least) to get things done, and failing that, there's a total of twenty-four hours in a day. If you can't get your shit done by the deadline, don't expect any sympathy.

You're not judged by the amount of time you spend in the office, or even by the amount of time you spend actually working as opposed to recreational websurfing. You're judged by what you deliver, and when.

The almighty visual.

8. Clients tend to be visually-oriented

This goes especially true for those not technically trained. When they take a look at what you've done so far, the first thing they're going to see is the front-end and layout. And from there, they'll form a snap judgement of how much work there is left to be done.

Perhaps you've finished coding all the Stored Procedures and security measures. Perhaps your code is now water-tight. But if your front-end is still the same white screen and black text as when you first started, the client is going to feel (despite his better judgement) that not much has been done. Don't hold it against them. If they were capable of thinking like technically-trained professionals, they wouldn't need you.

I've been guilty of this. When I work, a minimal front-end goes up first, and from there on I do a lot of back-end heavy lifting. But sometimes, I have to be reminded to work against my instincts and tinker a little with the front-end every time I finish some of the back-end work, so that my not-so tech-savvy clients have a better gauge of how far along the system is coming.

It's a royal pain in the arse, but it's necessary.

Slow down, dude.

9. Don't deliver too fast

If the client agrees that the next project milestone is deliverable in six days, and you can finish in two, all well and good. But only show him on the fourth day, at the earliest!

This is called "expectation management", and gives you valuable breathing space. You avoid the inevitable pickle when your client gives you something similar to do, but this time, expects it in two days instead of six.

I've been guilty of this as well, especially in an in-house environment. When someone wanted something, I didn't follow procedure to the letter. If something required an hour, I delivered within 15 minutes and moved on. It seemed efficient and convenient, but it was ultimately unsustainable for anyone following up on my cases. Yes, I was something of a cowboy cop in those days. But this would not fly in a vendor environment, especially if your client's getting billed by the hour.

Money's nice. Earn it the right way.

10. Don't work for the client directly

This applies if you're working as a developer for a vendor, and not if you're freelancing. But in the case of the former, it's a huge mistake.

Some clients will find your company's charges exorbitant, and come to the conclusion that paying you directly to take care of their stuff for them outside office hours, would be cheaper. They're right on both counts - your company has to cater for overhead and your salary, and still remain profitable, so the company charges more. And since you don't have to deal with any of that stuff, you could charge less.

It's all very tempting. Side income, what's not to love? But don't do it.

Firstly, even if it's not stated explicitly in your contract that you can't do this, and thus you may not get into any legal trouble over this, it's still blatantly unethical. By siphoning away your company's clients, you are biting the hand that feeds you. Not cool. This isn't about loyalty. It's about professional integrity.

And really, would you trust a client who would resort to something like this? And would any client trust a developer who would agree to it?

And that's the list!

Been guilty of any of these lately? If common sense was as common as its name implied, this list would not exist. But sadly...

You know you're reading this because I'm always sometimes right!
T___T