Should a programmer "think" for the client?
- by P.Brian.Mackey
I have gotten to the point where I hate requirements gathering. Customer's are too vague for their own good. In an agile environment, where we can show the client a piece of work to completion it's not too bad as we can make small regular corrections/updates to functionality.
In a "waterfall" type in environment (requirements first, nearly complete product next) things can get ugly. This kind of environment has led me to constantly question requirements. E.G. Customer wants "automatically convert input to the number 1" (referring to a Qty in an order). But what they don't think about is that "input" could be a simple type-o. An "x" in a textbox could be a "woops" not I want 1 of those "toothpaste" products. But, there's so much in the air with requirements that I could stand and correct for hours on end smashing out what they want. This just isn't healthy.
Working for a corporation, I could try to adjust the culture to fit the agile model that would help us (no small job, above my pay grade). Or, sweep ugly details under the rug and hope for the best. Maybe my customer is trying to get too close to the code?
How does one handle the problem of "thinking for the client" without pissing them off with too many questions?
