Transcript taken from: [http://www.script-o-rama.com/movie_scripts/o/office-space-script-transcript.html]

[Scene Initech. Bob Slydell and Bob Porter are interviewing Tom.]

BOB SLYDELL
So what you do is you take the specifications from the customers and
you bring them down to the software engineers?

TOM
That, that’s right.

BOB PORTER
Well, then I gotta ask, then why can’t the customers just take the
specifications directly to the software people, huh?

TOM
Well, uh, uh, uh, because, uh, engineers are not good at dealing with
customers.

BOB SLYDELL
You physically take the specs from the customer?

TOM
Well, no, my, my secretary does that, or, or the fax.

BOB SLYDELL
Ah.

BOB PORTER
Then you must physically bring them to the software people.

TOM
Well…no. Yeah, I mean, sometimes.

BOB SLYDELL
Well, what would you say… you do here?

TOM
Well, look, I already told you. I deal with the goddamn customers so
the engineers don’t have to!! I have people skills!! I am good at
dealing with people!!! Can’t you understand that?!? WHAT THE HELL IS
WRONG WITH YOU PEOPLE?!!!!!!!

First, I agree that the roles of System Analyst and Programmer are different, although it really wasn’t that long ago that we had Programmer/Analysts who were responsible for system level requirement specification and design.

Second, while a System Analyst must be in tune with the business / people issues, a Business Analyst is more generally responsible for defining the business requirements / needs which are then handed over to a System Analyst. Often these two roles work hand in glove to ensure that the business specifications are properly translated into system specification that address the technical specification / design.

I would suggest that a System Analyst with a hands-on technical background may prove to be better overall than one who does not. While abstractions are certainly useful, bad assumptions can and will result if there is no grounding in reality.

First, you had no real need to go into personality traits. Such a discussion does little more than distract from your topic at hand. A developer and an analyst are both problem solvers: some may solve a problem gregariously, some might sit quietly in a cube. The exact team role plays no real part in determining this.

Second, a developer needs to see both the forest and the trees in order to ensure that the business isn’t trying to make the system do something that it not supposed to do. To continue the analogy, if the system is supposed to be an Oak growing tree farm, a developer must know that in order to prevent the business from planting Pines. So too the analyst. However, as analysts tend to be higher than the transaction levels of the code, a developer needs to take corrective measures to prevent processes from flowing abnormally due to a business partner’s larke.

Some will argue that the languages thatdo things for you (like garbage collection) are actually worse, because they let you get lazy.