In start-up land it may different, but in most organizations, it usually goes down like this...
There's a person who needs something to be built and there are a couple people who can do the building. Let's just call these people the business owner and the programmers. Basically, a few people and a problem. And it work (for a while).
They all sit together in a room. The business owner tells the programmers what he wants. The programmers listen, ask some questions, propose some different ideas, make some corny jokes, and eventually they all get to some reasonable solution. They go back to their computers, type some keys, and in a few days or weeks go back to the business owner with something functional.
Sure, what they produced isn't perfect. Faulty assumptions were made, corners were cut, a few bugs were left lurking, but from the perspective of the business owner (who had nothing a few weeks prior), it's awesome. He's pleased. They deploy, or maybe they wait. Either way, things were built, and trust was formed.
They keep going with this cycle for a while. With each loop, the business owner and the programmers gain a little more respect for each other. "The business owner is a pretty reasonable guy, he wants to do the right thing", the programmers think. Likewise, the business owner starts to appreciate those guys with their funny terminology and why things aren't as easy as he might have thought.
At some point, however, the project is successful and people (customers, division leads, etc.) take notice. There's much more to be done. Features start coming in at a pace where the programmers can't keep up. They find themselves sitting in meetings more and writing code less. Moreover, features start to get implemented inconsistently - no one notices until late that feature A conflicts with feature B. If only there was a person who could off-load the annoying requirements work from the programmers, then the they could do what they do best: code. Enter the business analyst.
Now, it's the analyst who listens to the business owner, and just as the programmers did, the he wants to please. And he does. He parrots the business owners ideas, offers good alternatives, and writes up nice looking documentation to pass to the programmers. Sure, there are times when the analyst can over-promise or over-simplify, but it's only out of good intentions. He's trying to give the business owner what he wants. The business owner and the business analyst begin to jell. They talk the same language, and the business owner rarely pushes back.
As the bond grows between the analyst and the business owner, it begins to wear between the business owner and the programmers. Now, the magic of creation now happens between the business owner and the analyst. The best the programmers can do is to make good on the solutions the the business owner and the analyst have already birthed. Moreover, the programmers are just the harbinger of frustration. To the business owner, they bring only reasons why solutions aren't possible, questions about unclear requirements, and bugs. And more bugs.
Eventually, trust erodes significantly between the business side and the programmers. Without a strong relationship with the programmers, the business owners demands things that are untethered to technical realities. "Just make it happen". He begins to view the programmers as commodities. The programmers feel a bit under-appreciated. Apathy sets in. Without any political capital with the business owner, they start to swallow concerns rather than raise objections. Just get 'er done.
In both scenarios, the people are same. Everyone wants to do what's right. Everyone wants to please. But when you put a player in the middle, between the person who wants the work to be done and the people who do the work, the entire dynamic changes. Both the business analyst and the programmers want to optimize business owner satisfaction, but the former ends up doing it to the expense of the latter.
For the programmer in this situation,