Slashdot Mirror
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?"
This "anonymous poster" has been managing mainframers for five years, is a Unix nerd, and doesn't already know how the three cultures are different? Or are they just a Windows troll, stoking the flames of the OS holy wars?
--
make install -not war
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).
The difference is one programs Windows, one Unix, and one mainframes. As a fifth-year geek, you should take the rantings of Joel, ESR, and any other pointless windbag and send them to the bit bucket.
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.
US Democracy:The best person for the job (among These pre-selected choices...)
Why, in my day, we used stone punch cards we had to mine ourselves from the limestone quarry! Planning ahead made a lot of sense back then. Tell that to kids today, and they don't believe you!
Seriously, I think the real problem is management addicted to immediate change in production systems. This started when it was web content, and now they expect back-office stuff to change just as quickly.
Don't disappoint your bird dog. Go to the range.
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.
The word you're looking for is "user", not "threaded". From my experience, Windows coders are much more knowledgeable about threads than Unix programmers. Back when I was just learning some POSIX programming (I've been doing Windows programming forever) I'd ask even halfway experienced Unix programmers how to create a second thread in my program's process, and the usual response was "why on earth would you ever need to do that?"
You have tried to support your argument with faulty reasoning! Go directly to jail; do not pass Go, do not collect $200!
That IS a good question. In Unix, creating a new process and using IPC is so simple, you almost don't need threads. In fact, before POSIX threads, Linux threads WERE processes. The advantage you got over threads was cleaner separation of memory and variables -- always worth a lot when programming in three-star C. The disadvantage, of course, was that same separation meant that everything you wanted to share had to go through IPC.
You work at a University. Not a corporation. Things are very very much different even though you don't know that yet. Some day you'll leave, and then you'll realize how bad it really sucked there.
Yeah, man, 35-hour standard work weeks with flexible hours, seventeen paid holidays plus four weeks of vacation a year, classes for free, and great retirement benefits, plus an environment where experimentation and individual initiative are encouraged. Working for a university sucks!
Oh, and my own office instead of a cube -- oh, life is hard.
I've done a lot of mainframe development and a lot of Unix/Linux development; scarcely any Windows.
The main difference I see between mainframe development and *ix development culture is respect. With the mainframe you have to book time days in advance and work in the wee hours to make any changes. And you make damned sure that, when you're done, things work as they should.
With *ix development, things are laissez-faire. You send out a message a few hours/days/minutes in advance of some monumental change. Then you blame the users when they can't sign on to their system in the morning. Quote some recently-adopted standards if they argue.
Of course, I'm speaking of the early days of *ix. These systems are more and more critical, and the admins are trying to learn respect. But they're playing catch-up. There's nothing like the fear of taking down a $500/minute system to make you careful.
Windows development follows a similar pattern. The whole culture is so "personal computer" based that the concept of a year's continuous uptime is foreign.
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.
“Our opponent is an alien starship packed with nuclear bombs. We have a protractor.” — Neal Stepnenso
As someone who was a COBOL permie then contractor for many years all I can say to that is AHAHAHAHAHAHAHA. My god it must be really awful in the Unix/Windows world if the horrendous shambles that are 90% of mainframe projects are being held up as an example of how to do it.
The way to run a perfect project (at least to my mind) is:
1) The senior managers are there to say how they want the app to interface with the business. They have no say in how the application looks since they aren't the ones going to be using it.
2) Some end-users need to be involved early in the process so that the developers see exactly how they do their jobs, not how the PHBs think they do
3) Any non-trivial change to a signed-off business spec should require a good justification just like IT people have to provide a cost justification when they want something from management and if the justification isn't good enough then they'll have to wait (and maybe learn to get their requirements right before starting the design and coding the next time)
4) Non-IT people DO NOT get to set the deadlines. They can request it but if we say it'll take that long then usually it will and any cutting of deadlines usually mean it taking longer, having less functionality and being an utter bear to maintain/enhance.
I've worked in maybe 12 different organisations and only 2 even came close to any of those. Most didn't even do one of the above.
Does a Christian soccer team even need a goalkeeper?
Come back to me when you've graduated and have >10 years under your belt.
Maybe he doesn't have that kind of experience, but I have more than twice that, and I think you have all the earmarks of a 15 yr old Slashdot troll, with the bragging, profanity, "hahaha" in place of argument, "I make X dollars/year" blather, posting as AC, etc.
Normally I wouldn't waste time on an adolescent troll, but I want to make sure something is clear. I was one of the architects involved in the creation of Dreamweaver, and it we designed it to be used by programmers, not just Web designers. Among other things, it was designed to be used just as BitTrollent is describing: as a code generator for GUI elements. Typically, you'll lay out a page, or some page element such as a form, graphically in the GUI view. Then you'll switch to the embedded code editor and tweak it. Then you can either use the code editor to embed inline code in a language like PHP, or "code behind" (as in ASP.Net, using VS as he described to write the C#), or do what I've done on occasion and copy the generated HTML into your source in some other language (e.g. a "HERE document" in Perl or a C++ header file, perhaps after running it thru a preprocessor to turn tokens into method calls or whatever).
A troll who can't understand that real programmers who create GUI apps sometimes start with a GUI layout and code generation tool--or even with a simple drawing program--doesn't really understand the process. If he really has ten years of experience himself, it must have been pretty narrow experience to be so unfamiliar with such a common form of development.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Unixheads seem to claim that it's perfectly admirable to hack around the ASCII format for everything because it makes it easier to debug, whereas all I see is wasted entropy and bandwidth.
Wait until you have to troubleshoot issues with SMTP, POP3 and the like, then you will absolutely love the fact you can simply fire up telnet, connect to a server and manually test things by typing the protocol handshakes in. Not only are they all ASCII, they are easy to remember and make lots of sense.
Take it from this SysAdmin/Programmer, you'll never want to go back to a binary protocol again.