This post was originally published at sinewalker.blogspot.com.au on 18 July 2005

In reference to this Slashdot question about Mainframe Culture

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.

The sad fact is that, in today's environment, especially after the dot-com cowboys set Upper Management expectations, following Process is just too slow, or too expensive. Convincing management that a bigger cost up front will result in a lower cost in the long run is also futile when mgt sees it as “normal” for computer systems to break. After all, their Windows machine on their desk has been doing that for 20 years now, so it must be normal, right?

What matters most to managers or clients when deploying new systems these days seems to be “time to market”, and the only consent to quality is that the IT dept/company follows check-list processes like CMMI or ISO9000 which do not address the real issues and put too much into the Process rather than the Result. Also, when the system breaks, it's typically at the expense of the IT company that built it, or was stupid enough to agree to use the off-the-shelf product in the first place, so there is nothing to drive a change of behaviour from the clients.