Is it a responsibility of the software developer to understand what the customer meant with his request?

Question

Kind of a yes / no question and why?

Is it the responsibility of the software developer to understand what the customer meant with his/her request or is it the responsibility of the customer to properly explain his/her request to the developer?

The situation at work is currently "the customer already explained us, what he wants. It's your responsibility to understand the request, not ask more questions".

While English is not my strong suite, all the requests are written in obscure English with misplaced words and hard to understand sentences, some requests assume previous understanding of the system on my part.

I'm the 3rd or 4th developer of the system (the last developers quit the job) and that might be the reason the customer expects some understanding on the developers side.

The system itself is quite messy both in the UI and source code level. This looks like monkey coding to me - code and hope you get the request right, while not actually understanding the request.

I'm actually thinking about quitting the job, but haven't yet, given I'm not sure about who's right and who's wrong.

Answer 1

If it's your job to understand, it is your job to ask questions until you do

The person you ask may be someone who is not the customer (i often talked to an intermediary, who was in contact with the customer), so the ones who forbid you to talk to the customer should instead answer the questions themselves or refer you to someone who can.

But, in the end there has to be SOME kind of communication. If they deny it (and providing some documents that you don't unterstand is effectively denying communication), you should do as your predecessors did: run away, quickly.

Answer 2

When your clients and superiors leave you with a messy paper trail, the only thing you can do is gather as much sense as you can from what you have and start writing scenarios in plain English in an attempt to structure what knowledge there is about how the system is supposed to behave.

Given/When/Then scenarios make it possible for you to get into detail about what needs to happen and because they're written in plain English and they're structured, you can use them to communicate to your superior and client: "Listen, I've gotten to this point and I have no idea what the system is supposed to do here".

If your simply shunned away when you ask for additional clarification, even though you've invested effort to document everything that you do and do not understand, then the previous developers failed not because they didn't know how to communicate the specifications, but because it's impossible to do so.

Answer 3

In my opinion both (customer and developer) have to get the same understanding of the problem and its solution.

If you don't understand the request you cannot create the solution.

So you have to read the specs. If the spec is not clear enough (or there is no written spec) there should be someone who can give the answers.

I work in teams that have one person that can answer the business-questions. This business owner is either a member of the development-company I work for that knows the customers business or a member of the customers team.

Answer 4

It seems in your specific sitation, the project manager fears that the customer will be annoyed if they're asked the same questions multiple times (necessary because of developer turnover), and that this will reflect poorly on him and his company.

Of course, if you don't ask those questions, it will take you much longer to complete/modify the system and the result may not be what the customer wanted, which will cause more delays and ALSO reflect poorly on the project manager and his company, at least in the eyes of the customer.

There are some reasons why the project manager might choose not to let you ask questions:

1. He doesn't really understand the negative consequences or is in denial about them.
2. He's aware of the alternatives but knows the customer to be more likely to accept delays and poor quality than annoying questions.
3. He's playing political games: maybe he knows he's leaving the project soon and wants to keep problems hidden until then, or he's planning to blame you for the problems caused by this lack of communication.

IMO reason 2 is unlikely. In order to eliminate reason 1, try explaining the alternatives to him and ask him to make an explicit choice between them - suggest explaining the problem to the customer to reduce the annoyance. In order to eliminate reason 3, do this in writing so you can prove you were aware of potential probleams early on and tried to fix them. But to be honest, if you suspect this to be necessary you should probably get out there as quickly as possible.

Answer 5

I think it is always the responsibility of the service provider to ensure that the they have understood the clients intentions.

As experts in our field, it is not just our job to complete briefs but also to help guide our customers through the process of using our service, and this involved educating them on the possibilities we offer, and what we do now.

I believe a customer focussed approach is absolutely the way to do things, it is a tried and tested business model.

Answer 6

The customer and developers need to work together to refine their understanding of the system.

The software company needs to come to an agreement with the client as to what is required of each party, that is the fundamental aspect of a contract. If there is no "meeting of minds" then, in a very real sense, there is no contract.

Assuming that you are a competent programmer, if the specification is not clear then simply being told "It's your responsability to understand the request, not ask more questions" is rather silly.

Answer 7

This is based on some new information in comments on the original question.

The statement that

the customer already explained us, what he wants. It's your responsibility to understand the request, not ask more questions

comes from the project leader; the stated rationale is

that since I'm not the first developer on the system we shouldn't bother the client's representitive with more questions, but try to and if necessary, spend extra time interpreting the question

So what you're specifically being told to avoid is bothering the customer with questions.

Asking you to "spend extra time interpreting the question" isn't necessarily unreasonable. You should make a reasonable effort, or perhaps even a slightly unreasonable effort, to figure out what the requirements are based on what the customer has actually said. If nothing else, that's a valuable skill.

If that fails (and it sounds like it already has, for various reasons), then ask your project leader for help. Try to be as specific as possible in your questions, showing that you've done your homework. For example, rather than

what do these people want???"

ask something like,

In paragraph 17 of the requirements document, it says that the foobar must frizzle the frozzle; which of these three frozzles does that refer to?"

Or, if the requirements are really so badly written that you can't decipher them, tell him that.

I'd say that it's ultimately the project leader's responsibility to make sure that the requirements are understood correctly (it's certainly in his best interest for the project to succeed). But as a member of the team, you share some of that responsibility. If you show that you've made some effort yourself, and the project leader refuses to help you, then he's made it entirely your responsibility. If it gets to that point, make sure he knows that.

Answer 8

In a perfect world, there should be a list of features and specifications somewhere, something written on a contract bonding your company and your customer.

To answer your question, the developper should indeed understand what the customer wants, and have a written document so that both parties agree to the same vision.

Of course, this is not a perfect world and often there are no specifications, and if you don't have any written specification, well, this is going be hard. Is there anybody left in your company who work as relationship delegate with the customer, who could help you understand what the customer wants ?

If not, in your position, I'd try and get info from the previous developers, assuming they understood the task of course.

Answer 9

I think that the actual role specifying who takes care of understanding requirements varies depending on some of these variables

• Team size
• Company's standards
• The way the boss is used to work
• Different expertise among the team members

So if you are just a one man team, you should make every effort to get to the bottom of the requests. if you are new in an ongoing project, you should make an effort to go over the requests again with the customer.

EDIT: Most importantly, the customer may not know he made such poor requirements, and the process of gathering requirements is often long and tedious, but it's an important process, and if it falls on you because no one else does it, then you should do it with them.