Thursday, 14 February, 2002
Customers Don't Know What They Want
If there's one thing every junior consultant needs to have injected into their head with a heavy duty 2500 RPM DeWalt Drill, it's this: Customers Don't Know What They Want. Stop Expecting Customers to Know What They Want. It's just never going to happen. Get over it.
The emphasis is his. I agree with that, but then he gets it wrong.
He goes on to say that, since the customer doesn't know he wants, it's up to you as a developer to obtain the domain knowledge and build what you think the the customer wants. That, in my experience, is a recipe for disaster. I usually agree with most of what Joel has to say about development, but he's dead wrong on this point. In 20 years of writing software for hire, I have never been successful using that method. The worst projects I've been on are not those in which the client hovers over me every minute, but rather those on which the client is studiously disinterested until delivery time, and then completely surprised when the software doesn't work as expected.
If you're building software, be it for a product, on contract, or part of an in-house system, you must get regular input from your prospective users. If it's important enough for them to hire a programmer, then it should be important enough for them to take the time to explain the business process to the programmer and help design a usable system. Certainly the programmer has to learn something about the business, but he shouldn't have to become a domain expert for every project he's assigned. It takes years to become competent in some fields. Do you really expect a programmer—even a really bright programmer—to become an expert and create a program to solve the domain-specific problem in a reasonable amount of time? Have fun, guy. Me? I'd suggest you walk away from a contract if you think the client won't have the time to spend with you.