Question

I am a junior programmer. Since my supervisor told me to sit in with the client, I joined. I saw the unsatisfied face of the client despite the successful (from my programmer’s perspective) delivery of the project!

Client: You could have included this!
Us: Was not in the specification!
Client: Common Sense!

As a programmer, how do you respond in this situation?

Answer 1

What you should do to avoid this situation:

Explicitly spec out what will be included and what will not be included.

The problem probably comes down to the unspecified parts of the spec:

• The client thinks that unspecified stuff should be in, i.e. it was implied.
• The developer thinks that unspecified stuff should not be in.

For future specs that you have, you should have a catch all statement, that explicitly states that if something is not specified in this document, it can be done after the original specification is done at an additional cost.

What you should do in the current situation:

Other than learning from your experiences, you should come to some compromise with the client.

Example: I will do this feature that you feel is common sense, but for all future additions/changes it will have to be spec’ed out explicitly.

I.e. you will have to do a little more work, but it is worth it in return for the catch all explicitly spec’ed agreement your client will enter into.

Bad spec?

Was it necessarily a bad spec? No.

It is impossible to mention everything your clients may expect, so it is critical to have this catch all statement mentioned above stated clearly and explicitly in your spec/contract.

Other ways to reduce the problem:

• Involve the client early, show them early prototypes. Even if they don’t demand it.
• Try not to sell the client an end product, but more of a service for working on his product.
• Consider an agile development model or something similar so that tasks are well defined, small, paid for, and indisputable.