[fit2rule]

You are reversing authority. It is the executive whose system you are computerizing who needs to state how things should work - and your job to make it work. If it takes longer than the executive thinks it realistically take, if you can't explain it to him in a way that makes him a master of the situation: you are not doing your job.

So even arguing from the perspective of "my opinion must be respected" is, to me, an indicator of your own failings as an engineer. Its always the engineers job to make sure the system they are building, works for their users. Your boss is a user too.

If you have to have an opinion be respected, you haven't been writing your docs. Opinions don't build working software systems - written materials do. So making sure they're read and understood is actually your job, and complaining about others not having respect for this fact, means you're not doing a very good job.

Just my opinion. Respect it or don't.

[Fr0styMatt8]

That's a fair criticism and I do find communicating WHY something is difficult, especially to a manager who doesn't code, to be a challenge at times. It is something I'm conscious of and I'm working on. I agree that respect has to be earned.

For what it's worth, I'm not talking about dictating what the customer's requirements should be (as in "That's a stupid idea, I think this is what you should do instead"). I'm talking about "This will take three weeks even though it looks like a simple change because there are still plenty of unknowns" ... "But we have already promised the customer that this will be done in a few days (without consulting engineering), can't you just do it quick and then we'll fix it up later? (but later never comes)" type stuff. Or never being given the time to implement a test framework or refactor and then being criticized because customers find bugs. That kind of thing I find difficult and frustrating.

[fit2rule]

I understand you. But I still really believe that if you're in this situation, you've lost control of your customer - and this is your job, no matter what. Sure, users are stupid. We know that. But making them smarter - whether its through a smart application, or a smart process, or smart documentation, or smart other-enlightenment processes .. this is the job of good engineers. Strive to be better at educating the user and you will become a better engineer - its just a truism I've noted.

(Not to say it isn't necessary sometimes to get the gripes off ones chest.. just that it should be seen as an indicator of a failure, somewhere, to engineer solutions for the user.)

[derefr]

So... what happens when the client says "I want a database that's C, A, and P" or somesuch, and then just doesn't believe you/ignores you/etc. when you explain what's wrong with their request? Presume "working in another company" isn't an option, because, in your experience, every other company will do the same thing to you.

I understand informed consent—a doctor can't shrug off the responsibility to get the patient informed enough to say yes to what they're doing with a "just trust me." But sometimes what the user is paying you for is, exactly and precisely, to not have to learn X in order to do X.