"If a developer doesn't know exactly what they are supposed to do, they should just GUESS what they think should be done and move on. "
Once the words left my lips, a technical team lead at the table paled and began to argue about how that statement was totally incorrect. I was puzzled for a moment, but then realised this person probably thought I was implying that they should not EVER go back and ask what should be done. In addition, I think they heard me imply that developers shouldn't ever ask questions in general.
This was not really what I intended to communicate and in retrospect, my choice of words was unfortunate. To clarify, I obviously think people should ask questions, they should openly challenge requirements that are vague, ambiguous, or contradictory. More importantly, they should be free to use their best judgement in the absence of specific instructions. But if it is going to take 24+ hours for a business client (or the boss) to get around to answering your question, make an educated guess as to what you think they MIGHT say, make a note for future generations, fire of the question asynchronously, and continue to work toward a solution.
I'm not suggesting that this is ideal, but nothing ever really is ideal. As an example, a better situation might be that the business client or representative user is sitting within arms reach of the developer and they can simply answer any question immediately. If this is the situation then of course: ask away, have a rousing discussion, argue about it. My point is more that software development is a partnership and having the development team simply delegating every decision to their business partner (or the boss) is a sure fire recipe for disaster. In addition, it will very likely lead to a buffalo problem
In hindsight and to clarify, I think my statement really should have been:
"In the absence of specific instructions, coworkers (peers, subordinates) are authorised to exercise professional judgement to select the best course of action without fear of reprisal"