> If the former, you'd be guilty of overengineering and missing your client's objective (by being too costly, too complicated, etc). If the latter, why would yo

> If the former, you'd be guilty of overengineering and missing your client's objective (by being too costly, too complicated, etc). If the latter, why would you care to explain and "do the right thing" (the client will not pay for things he doesn't know are important)? Too often developers do what we see as 'right' technically, which is not necessarily 'right' for the client / project. It's not something to be 'guilty' of, just something to be aware of. Although there is a balance - I've often fought for things and had them save the client's ass later. And as for explaining why something is important - because the client should have an appreciation for why they hired _you_, not someone else.