Well, I think that you can probably write a compiler from "yes, if" to "no, because" and vice versa. Example: Yes, if the '"yes, if" attitude' is defined as '

Well, I think that you can probably write a compiler from "yes, if" to "no, because" and vice versa. Example: Yes, if the '"yes, if" attitude' is defined as 'never disagreeing with anyone ever, since no one ever attempts to abuse positive-thinking engineers.' But the real question is like the programming language question - what's the most expressive and useful in a given situation? Sometimes an idiom is not a good fit. I always responds 'yes, if' -- to people I know won't abuse it. That's most of the people I work with. But some entrepreneurs, Project Managers, clients and so forth are simply not to be trusted with a "yes, if." The goal is to avoid those kinds of shady operators, crappy projects, and hostile clients. But sometimes you end up working with them, at least as bit players in a business relationship that is a good fit. Especially as a freelancer, I don't know anyone who can avoid it 100% of the time. For instance: even when working with a great organization, some project could have a weak link in a project management role. It will happen to you. And all you can do is try to do good work while extricating yourself as soon as possible. What should I tell one of those not-very-trustworthy people if they ask something ridiculous? Does compiling it to Yes-If prove more expressive? Examples: Yes, if the laws of space-time, human nature, physics and the combined sum of human experience weren't arrayed in battle order against you and your terrible idea. Yes, if I could trust that you, a non-software PM who shifted into this job from Accounts with no training heavier than that provided by Clippy, have correctly assessed the stakeholder requirements and risk around this new feature that you think is required by 'EOD Thursday.' Sometimes, there is an answer, and it is No. Because. Sometimes you should signal risk and danger in your response, because risk and danger are present in their requests, and you must be sure that they are weighing those dangers. 'No, because' (or 'I'd advise against it, but here's what it would take', which is closer to what I actually say in those situations) definitely has its place. NOTE: this is not non-technical PM hate. I may currently have two PMs, on projects for two separate fortune-50 companies. Both PMs may be non-technical, but one might know how to be a PM, and specifically on a software project, and the other might not.