Not the best of articles, IMHO. It has too many broad statements and seems to be trying to be a "one size fits all" bit of advice.
I like the metaphor and agree with this sentiment: "the problem of understanding what customer needs, as opposed to accepting what the customer is asking for".
A few points:
1. The customer has a say in the requirements. They are often the domain expert. Even if they have no expertise, they need to be regularly consulted otherwise you still run the risk of delivering software that no value to them.
2. Understanding the business and eliciting requirements is often beyond the ability and scope of the software developer. These are the skills of a business analyst. Of course, developers can and do have these skills, but it shouldn't be assumed that they do.
3. Proper business analysis may lead to a solution that doesn't involve custom software. The article doesn't seem to allow room for this.
4. Implementation is often important to the customer. Many won't be comfortable to leave everything "below the surface" to the software developer.
I like the metaphor and agree with this sentiment: "the problem of understanding what customer needs, as opposed to accepting what the customer is asking for".
A few points:
1. The customer has a say in the requirements. They are often the domain expert. Even if they have no expertise, they need to be regularly consulted otherwise you still run the risk of delivering software that no value to them.
2. Understanding the business and eliciting requirements is often beyond the ability and scope of the software developer. These are the skills of a business analyst. Of course, developers can and do have these skills, but it shouldn't be assumed that they do.
3. Proper business analysis may lead to a solution that doesn't involve custom software. The article doesn't seem to allow room for this.
4. Implementation is often important to the customer. Many won't be comfortable to leave everything "below the surface" to the software developer.