current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 2 down vote favorite

it seems that most of the programming exercises that I am currently doing, are a little bit ambiguous when it comes to specifying what should I do.

When programmers work with clients, are the clients ambiguous as well about what they want and I should learn to guess?

share|improve this question
7  
Most clients don't know what they want. They have this grand idea in their head of what they think they want. It's up to the development team to pull it out and define it. –  Jeff Vanzella Sep 4 '12 at 22:59
10  
On average I would say clients are more ambiguous than exercises. Also, just because clients say they want something doesn't mean it's really what will make them happy. –  psr Sep 4 '12 at 23:06
    
There is a subject that you need to know about, it is called Requirements Engineering or Requirements Management. Programmers are not the best qualified people to gather requirements anyway. In many cases this is the job for Systems Analysts or Business Analysts. Guessing is bad. –  Emmad Kareem Sep 5 '12 at 0:55
1  
@EmmadKareem While analysts often should and do write the spec up and define requirements, it is very important that the actual developer do their own requirements gathering from the analyst, filtering the product requirements into technical requirements, many times in this filtering process the product requirements should or must change due to technical reasons the analyst couldn't have known. –  Jimmy Hoffa Sep 5 '12 at 2:03
    
@JimmyHoffa, very true. –  Emmad Kareem Sep 5 '12 at 2:45

2 Answers 2

up vote 17 down vote accepted

If you guess what a client wants, you will ... fail.

Clients do not typically know what they want. They just know how an existing process works. Many times it is your job to help them bridge the gap from the "old way" to the "new and improved" way that is possible using computer software (or new computer software).

Respect what they know, and help them learn what you know. Then you will not fail.

share|improve this answer
    
So with clients i can go and discuss with them what they want, correct? –  Mohamed Ahmed Nabil Sep 4 '12 at 23:00
1  
That is usually expected. As @gahooa said, if you guess what they want, you will fail. Discussion is the only way to create a successful project. –  Jeff Vanzella Sep 4 '12 at 23:02
1  
I agree with everything said here but it's important to know this caveat: What @gahooa is dictating here in a very simple way is not simple, requirements gathering is a talent that takes many years to become good at. It is a very important skill of a good engineer, the best coder who doesn't know how to illicit the desires of his clients is doomed to write great code into a system no one wants. So do take your time and be attentive, thoughtful, and studious in the process of gathering requirements, do not treat it as a minor part of your job of little import. –  Jimmy Hoffa Sep 5 '12 at 1:59
    
I'm a big fan of User Stories, but they need to be written by the user! Start any place in the process and say, 'When the user sees X, what do they want to do? What do they click? What if Y goes wrong? By forcing the user to write the User Stories you a) make them articulate their need, and b) make them deeply invested in the development process. After that (which isn't easy), things get easy! :-) –  Peter Rowell Sep 5 '12 at 3:55
    
I'm a big fan of the question "what is the big goal you have in mind?", which is something a lot of people forget to ask and a lot of clients don't express well enough initially. –  Spoike Sep 5 '12 at 8:45
up vote 2 down vote

University/school exercises are sometimes intentionally vague as they are testing your knowledge of the subject matter as well as the programming language. For example, a exercise that requires connecting to a remote host may not specify the application should support both a hostname and IP address.

That said, requirements in practice are not a monolithic, one-time thing. Even (hypothetical) customers that provide detailed, unambiguous requirements up front may change their mind during the development as they learn more about the possible solutions and requirements change over time. Key points to consider:

  1. Keep open communication between the developer and the customer. Scrum does this through the sprint process and the product owner concept, for example.
  2. Make incomplete versions of the product available, such as through a beta program. Getting a working application into customer hands gets the best feedback you can.
  3. Make time in the schedule for handling changes to requirements. Planning and expectation setting is half the battle.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.