This post was originally published
at sinewalker.blogspot.com.au on 18 July 2005
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
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.