[pbnjay]

> + One person is the technical expert. The other party hires them for their judgement. The contract acknowledges that.

I love this one. Anyone have ideas on how to apply this to software development? I really hate it when clients say "I want X" and I have to take an inordinate amount of time telling them why X is a very bad idea both in terms of effort and value. Generally this is during scoping so I have no way of billing for the time.

[pekk]

The consensus seems to be "telling them why something is a bad idea at length is part of the job" and "doing it the stupid way at additional cost, because they insisted, is part of the job."

But I think we can go too far emphasizing pleasing the client sometimes. I don't think it's so rare to see genuine conflicts of interest, like squeezing for unreasonable deadlines and scopes, where the problem can't really be solved by just charging more.

If a client makes overly aggressive demands and won't listen when you take the time to tell them politely what you can do, is it better to be exploited mercilessly and risk breach of contract, or to cut your losses, swallow your pride and find another way to pay the rent?

[brudgers]

The best way to convince a client they are making a mistake is to do it the way they asked and do it the way you think is better and then show them both. Sometimes the client sees their error. Other times it turns out that the client has an unarticulated need that gets teased out and the final design incorporates both the ideas of the designer and the unarticulated need.

It's important to realize, that often the client is more experienced with their requirements, i.e. the business domain. And their understanding may be sophisticated in ways that are contrary to the naive take of an outsider.

[brudgers]

Be professional. Part of that means knowing how to produce reasonable estimates. That requires having a plausible roadmap at the start.

In some ways, software will always be harder because the artifact in a construction project is the building not "the blueprints". If the design is dragged out, the building doesn't get built.

On the other hand, the way an architect handles "I want X" is by showing them that it is a bad idea. Showing means providing a design that incorporates "X" and one without. The assumption that everything will be done multiple times before it is right, and indeed that doing it multiple times makes it better, is what separates architecture from engineering in AEC.

Understanding that doing things multiple times is just part of the job and that falling in love with one's own ideas is a bad habit can be learned. It ain't easy. But in the end, the architect walks away and the client lives in the building. Software is similar in that way.

[danbmil99]

what you call "scoping", beyond high-level goals (< 1 hr to explain) you should refer to as "development of detailed requirements and specifications", and should be charged for by the hour just like coding.

Your ability to tease out what really needs to be done from a customer's hand-waving wishlist of vague features is a key component of what you are being hired for. That skill is worth more in general than straight coding, and should be compensated accordingly.