Coding in front of the client?

Question

I was wondering what peoples opinions are (I have made this a community wiki) on coding in front of a client?

I was in a meeting today with a client who was highlighting some bugs and requesting some changes and whilst other people where talking amongst themselves I decided to fix a couple of the bugs (Wording changes really). I showed them and immediately wondered if that was a good idea.

One part of me thinks it shows efficiency and dedication to a quick turn around. Another part of me thinks it is giving away too much and the client may think that if bugs can be fixed in 2 minutes why do they get big estimates for some other work.

/Edit/ Sorry, I should clarify, the talking amongst themselves was during a break, I was obviously giving my full attention during all parts of the meeting!

Answer 1

IMO that would get them thinking "So.. it's THAT easy and I pay this much for it?" or something among those lines. Of course, every client is different but I believe this would be the general opinion.

Answer 2

My experience over the years has been that it's almost never a good idea to code in front of the client.

It creates mistaken assumptions and wrong expectations in the mind of even the most trusting and relaxed client.

The ten minute fix may be the only thing they ever actually see you work. With that in mind, they will have a harder time understanding why something takes days, weeks or months to complete.

Answer 3

Those weren't bugs, they were presentation changes.

I wouldn't do this for the simple reason that it may give the impression that you are not fully engaged in the meeting (even if they were "talking amongst themselves", you'd not been dismissed).

Answer 4

It's a judgement call. If you suspect that your client is of the "It's just typing after all!" variety, then do not code in front of them. Seeing a quick turn around on a easy bug is something that you will have a hard time living down.

If they are more sophisticated, they may appreciate seeing that you are not trying to milk them over every trivial issue. That will increase their trust in you, and they will be less hesitant about signing off on longer-term changes.

I've done a fair amount of coding in front of clients as an approach to training their engineers in new technologies, and I found it to be very stressful. I'd go out of my way to avoid it for anything more than a couple of hours every once in a while.

Answer 5

I think the only time I would ever code in front of a client would be when a demo had fell down and I was desperately tried to get it up and running again...

Though I'm sure my redundancy would follow on from that!

Like most I would expect the answer would be to never code in front of a client. In most cases I doubt you would know their technical skill, or what they're going to think for that matter... Very risky.

Answer 6

I personally feel that a lot of it would depend on the client.

It seems like it would be a little boring if they didn't have at least a cursory exposure to application development. Additionally, if they did have at least a cursory exposure, they wouldn't have a problem with your estimates (assuming your estimates are fair and justified against the actual hours expended on a project).

I might mock in front of the client, but I don't think I would ever code. A better deliverable (IMO) would be taking requirements and releasing the next day or in a short iteration.

Just my two cents.

Answer 7

I have never coded in front of the client, however I have been forced to do it (from another room) during a meeting to fix bugs on the fly as they were testing a shocking piece of coding (not mine originally).

I would hope that I never have to do it again as you are more likely to generate even more bugs this way as you are not properly thinking the bug fixing solutions through.

Answer 8

No way.

• You can come back later with an entire list of items that you have accomplished including the minor change. This carries a greater impact.
• Talking about the change after the discussion is initially done can potentially backtrack the meeting, making it longer. At best, it ruins the flow of the meeting.
• If your change is incorrect, you'll look like you're error-prone or imprecise.
• If your change comes up in a code review, your reviewer may thank you for remembering the change. You want as many of those opportunities as possible.
• If the client is technically savvy, it's not impressive to make a minor change. They may feel that you're not paying attention to the meeting while you are making the change. At the very least, you are losing eye contact with the client and typing while they are speaking.
• If the client is not technically savvy, they may have an issue with how much you are billing given the ease of your solution and not understand why other tasks are so time-consuming.
• If you have resources reporting to you, delegate it and have them manage any subsequent changes. Then, you're a leader :)