I've noticed in my time developing for a large enterprise that there are three broad categories of developer. (Of course there are more, but for the sake of this discussion I believe this distinction is sufficient.) They are:

The profi programmer

This type of programmer is usually (but by no means always) a permanent employee. They usually work in a dedicated development group, and tend to take a long view of situations. The code they write tends to be, by necessity, written to handle the bigger picture, such as long term maintenance, portability, extensibility.

The happy customer programmer

Often, but not always, this type of programmer is a contractor. Their primary focus is to keep the customer happy. This means they tend to avoid any form of confrontation with the business contacts they work with. They usually work with contract renewal or immediate customer gratification as their primary objective. (Note that gratification is not the same as satisfaction. Gratification is an ego thing, satisfaction is a results thing. They are often orthogonal.)

The JGID programmer (Just Get It Done)

This type of programmer takes the shortest path to a working solution. Meeting customer requirements is important, but if corners need to be shaved to get the project working quickly then to hell with the spec. This type of programmer usually has no long term vision at all and simply does their best to get a particular problem off their table as quickly as possible, no matter how stupid the project is.

I bring this up because I have observed a pattern related to these three personalities. Its common I find to have people from the business approach a developer and say something like "can you do X, Y, and Z using P, over T without using U?".

The JGID, tends to evaluate the situation quickly, and then say yes or no based on their tools and skills. If they say yes then they implement quickly, with minimal questions, and with minimal thought about how their work fits into their companies bigger IT/IS framework. If as they go they discover the specs are insufficient they tend to quickly get frustrated, and will drop the project at the first opportunity, or simply make quick decisions on their own, and hand over a partial solution to the customer with a comment like "should have given me better specs, you get what you ask for."

The happy customer programmer tends to simply say yes. They don't mind going back and forth to business to refine, redo, and re implement things. As long as the customer is smiling every time they walk away what they have actually produced is irrelevant. And if it takes an inordinate amount of time, well that's just fine, as I said usually they are contractors and are thus quite happy to waste time.

The profi tends to look at such a scenario and say: "No I cannot do this. First off what you have there is a solution. I don't implement solutions. I solve problems. Come back to me and tell me what you want done, and I'll put together some proposals for you, but I certainly wont do what you've just asked until you tell me a lot more about the real problem at hand." They are worried much more about the overall framework more than any individual project. They know that simply deploying a crappy solution, no matter how happy this will make some particular business person, is not the prime objective. If this solution ends up wasting hours or weeks of valuable time and resources then they don't do it.

Now personally at various times I've been all of the above and worked with all of the above. But I've come to the conclusion that its only the profi that I want to be and work with. The other types are long term a waste of time.

As an enterprise programmer you don't work for a individual. You work for the company. And if saying no to some (possible self important) businessman is long term in the companies benefit then you should say so. Saying No to the business is fine if you can justify it. Saying yes to business and then wasting your time and their money does no-one any good.

So for those in the position to do so (I acknowledge that many contractors aren't in this position), when in your judgement you think something is a bad idea Just Say NO. The business almost never can do anything against you if you do so. It will be their job to justify why you should have said yes. And frankly they probably wont even bother. IMO most likely you and everyone else will be better off. Also, once in a while you'll find that business person comes back with a good description of the underlying problem and lets you propose some solutions that are viable. Often they are quite surprised to discover that Y and Z are already done, there is no reason to either use P or not use U and T has nothing to do the problem anyway. Even better, when this happens the customer usually sings your praises loud and far. (Which is always nice :-)

I look forward to having this meditation ripped to shreds by the many more experienced monks than I. But for now, the most important lesson I've learned that im trying to pass on here is that saying no isn't a bad thing at all.

This also has some overlap in the monastery. Questions here are often along the line of "how do I implement solution X", instead of "how do I solve problem Y". Its the latter ones that I tend to answer. The former ones (unless interesting on their own) are usually ignored.

PS: "profi" means professional. (Possibly with subtle overtones of "permie" as well) Which is not to imply that contractors and the JGID aren't professional, its just that the term that has been associated in my mind with this type of programmer.