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?
5
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.
5
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:
- Keep open communication between the developer and the customer. Scrum does this through the sprint process and the product owner concept, for example.
- 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.
- Make time in the schedule for handling changes to requirements. Planning and expectation setting is half the battle.