What is Mainframe Culture?

An anonymous reader asks: "A couple years ago Joel Spolsky wrote an interesting critique of Eric S. Raymond's The Art of Unix Programming wherein Joel provides an interesting (as usual) discussion on the cultural differences between Windows and Unix programmers. As a *nix nerd in my fifth year managing mainframe developers, I need some insight into mainframe programmers. What are the differences between Windows, Unix, and mainframe programmers? What do we all need to know to get along in each other's worlds?"

Comments

One difference

[Prof. Pi]

Unix and mainframe programmers are more likely to know multiple systems, out of necessity, and consequently have a more general understanding of the commonalities of all computer systems. Windows-only programmers are more likely to know The Microsoft Way, and only The Microsoft Way. They're less likely to know standard terms, and will only know Microsoft's replacement terms. At least in my experience (and these are tendencies with plenty of exceptions).

Good question.

[BrynM]

I'm a bit rusty on the mainframe side, but I'll give this a stab.

The main difference is one of resources. The mainframe folk utilize a shared resource: the Mainframe System. You may have parallel hardware, but from their point of view it's a single system. There's no ability to install a quick machine to use as a test server. Sure you can have test CICS regions or test OS partitions, but if you bring the hardware down you bring the datacenter to a screetching panic. Worse, you can piss off the operators and have 0.00001%CPU for the rest of your tenure. This keeps a certian unspoken level of panic about. Don't worry if you notice it bubble up when one of your coders fucks up. The panic symptoms will pass as it goes back down to it's normal level. It won't go away though. ;-)

Which brings me to scheduling. Remember that production=batch and batch knows no sleep. When code goes to production, it's just as bad for the stress level as a major version release of other software or a website launch. Unfortunately for the MF coder it happens a lot more often. Having to talk to your operators when you can't even see straight (from sleep or other things) takes something that is unique to this kind of coder. On-call programming takes talent and some craziness. If you can find where that is for each of them, you will realate to them well.

One last thing: make your coders work in operations for at least a week. They will have a better understanding of the hardware end and productivity will go up. There's a reason that the best coders are in the computer room a lot.

On the difference

[Tsiangkun]

Unix programmers like their code like the old legos. Each piece might be a different size or shape, but the bottom of one snaps onto the top of another and the ordering and number of pieces used is left as an excercise for the reader. With experience, anything can be built with the pieces, and yet each piece is simple and easy to understand.

Windows is like the new lego sets. You get specialized premolded parts suitable for one specific task, plus two or three additional add-on pieces that give the illusion of being fully configurable for any task. You can build anything you want with the new legos, as long as you only want to build what is on the cover of the package.

Yeah, that's it in a nutshell.

Mainframe is process-centred, *nix/windoze is not

[sinewalker]

Appart from the obvious religious stuff about GUI (or lack of) and user-centred interfaces (or lack of), the biggest difference, and the biggest advantage that Mainframe brings is it's culture of process and change control. It is something you should strive to let your Mainframe masters pass on to the *nix/windoze padawans before they die of old age.

I am a *nix padawan, but, crocky technology asside, I'm frequently impressed by my Mainframe elders, their ability to deploy code to Production environments that works *the first time* nearly every time, and their ability to communictate technical changes necessary to fix broken code in the middle of the night in the 0.1% of cases where they failed to get it working first time.

Key values that I have picked up from my masters, and which should be inherrited by both *nix and PC/Mac enclaves are focused around Engineering principles. Mainframe guru's program like a civil engineer builds a bridge. No shortcuts are taken unless it can be proven that it is safe to do so. Testing is carried out in stages and test results must be submitted with the change request before a program migrates to Production. If a program must "abend" (Abnormal End) then it should do so noisily and with as much information as possible. If it finishes cleanly, little information is needed other than this fact.

These closely follow the advice Raymond has encoded in his book, but there is probably much more that your Mainframe gurus know that you should cherrish and extend to your newer team members.

Forget about the religious wars, the technology changes and the "focus" of your programmers on users or other programmers. Get the real truth from your Mainframe masters who have seen it all pass before them but have learned the hard way how to make a stable computer environment that stays up, even on cruddy mainframe technology. If their attitudes were adopted by people fluent in today's fantastic systems, all people would benefit.