Two weeks ago I was on a Project Management course at work, which was highly enjoyable and very involved. Project management for a company this big is evidently a very complex and rigorous process involving all kinds of procedural steps and checks and formal presentations of stuff. That was one aspect of the course: the System, creating a proposal and then delivering it to dangerously executive executives.

The other half of the course was basically: "Agile is good, Agile is great, we surrender our souls as of this date".

There's a lot about modern software development that strikes me as, well, blindingly obvious. As in, "Why would you ever do things differently?" In a small project, deciding what tasks to focus on in the short term is a good thing. Limiting yourself to only a certain amount of development - one iteration - and always ending up with a slightly more useful, stable product at the end, is smart. Listing out all the various tasks ("user stories", "technical debt") that you want to do and having a well-structured discussion about their relative difficulty and the amount of time each will take? Five-minute daily meetings to find out where everybody was yesterday and is today? A clear distinction between the Lead Technical Bod and the Lead Non-Technical Bod? All of this makes perfect sense to me. For small projects.

Whether it works on a product as big as the ones that ICBM manufactures and sells is still as-yet unproven. We seem to still be in a transition phase at the moment, and an organisation this large doesn't turn on a sixpence, changing direction rather more like a petroleum tanker. This stuff has been developed Waterfall Style for decades, and the adjustment process from that to this isn't proving to be without its hitches. Something like CICS has run basically faultlessly for forty years. So do you want to develop something like that in any way other than "slowly and with extreme, extreme care"? We don't know Agile scales yet, but we're being asked to believe that it's perfect, it's the Way Forward. I'd love nothing more than that. I'd love it for everything to turn out fine, because quite frankly, I work here. But if something has to be believed in for it to work properly, it doesn't work properly. This is Britain, nation of sceptics.

*

One week ago I began the System z certification masterclass crash course, which the previous bunch of grads took nine months over and which we're doing in eight weeks flat. System z is a hardware platform, the latest iteration of which is the z10 mainframe, combined with the z operating system, z/OS.

ICBM System z is the Stonehenge of computing platforms.

It is monolithic: z10s are enormous square standalone black things with ridiculous power requirements, more closely resembling the monoliths of 2001: A Space Odyssey than any machine to date, both in form factor and processing power. It is ancient, tracing its roots all the way back to System/360 which was released in 1963 and was programmed using punch cards. It is terrifying. Unwieldy. Impassive. Inscrutable - mainframe programming is on a whole other planet from your conventional Linux and Windows and miscellaneous systems ("distributed platforms"), and I will shortly share a few of the major brain-freezes which I've encounted so far in my limited experience with the topic. It's phenomenally reliable: it's been doing what it's been doing since the dawn of time. And finally, you will never, ever be able to make it go away.

System z is a living fossil; it is computing archaeology; computing palaeontology. System z is an example of the principle "If it ain't broke, don't fix it" carried to its logical extreme. System z and its predecessors haven't broken for forty-five years: the "z" stands for "zero downtime" and some of these machines have been running continuously for decades without a reboot. Nor, therefore, have any of them ever been "fixed".

It uses EBCDIC, a character encoding wholly incompatible with ASCII featuring such delights as non-contiguous letter sequences. It was, from 1983 to 2000, a 31-bit operating system. (Yes, thirty-one.) It does things with virtualisation of system resources and operating systems themselves that were thirty years ahead of their time, but all the interaction with z machines is still performed through an archaic green screen system from the 1970s, running in an emulator, with a 24x80 character screen. The screen is 80 characters wide because that is how many characters you could fit on a punch card.

The output from the Job Entry System, however, is 132 characters wide, because that was how many characters you could fit on the line printer where the output came out. Nowadays, of course, the output comes to the green screen. So you always have to scroll left and right to see all of it. The keys for scrolling left and right are F7 and F8. For scrolling up and down? F10 and F11. No, Page Up and Page Down will do nothing.

To enter a command? You hit the right Ctrl key. "Return" will do nothing. "Enter" will work, of course, but, AS YOU KNOW, "Return" and "Enter" are separate keys on your keyboard. "Return" is just above the right Shift key. "Enter" is way over next to the numeric keypad.

To copy a line of text, you have to go to the small command area which exists to the left of every line and type a "c". Then hit right-Ctrl. Cutting and pasting is about as tiresome. To indent lines in bulk? Also tiresome, but don't worry about it - most code will break if you start doing crazy things like adding whitespace. Don't you love a text editor which requires the use of a command line to work properly?

"Undo" is disabled by default!

z/OS does not have files. Or directories.

Job Control Language, the language through which tasks are started and stopped (oh, everything is a batch job by the way; even the terminal session you're using to interface with this thing) isn't Turing-complete because it can't do loops. It is case-sensitive, by which I mean that everything must be in upper case.

Every valid line of JCL begins with a double slash, "//". Anything else is likely to be parsed as a comment. Because the screen is 80 characters wide but 8 characters are taken up by the aforementioned command area to the left, there are always 8 characters missing off to the right of the screen.

JCL does have subroutines ("procedures"), but get this: every line in a JCL proc has to have a label, and when you call a procedure, you can add extra lines below the procedure call to alter the contents of the procedure on a per-line basis. This was originally the only way to pass a "variable" into a procedure. Got it? That means that, as soon as you create a JCL procedure which is a really useful utility for other people, you can never change it again because someone, somewhere out there, is relying on it to continue to work exactly as it always has, in order for their code to work. If you so much as relabel one line of your procedure between one software version and the next, you will break somebody else's program.

And no, you cannot change things to make them better, because "somebody else" is Walmart, "somebody else" is Barclay's Bank, "somebody else" is the Tokyo Stock Exchange. I don't know that those three use System z specifically, but that is the scale of customer we are looking at here. z is this software developer's nightmare: it is something which can never be improved because so much depends on its extreme backwards compatibility and its pedigree of never failing and never changing, a pedigree apparently entirely at odds with the Agile manifesto.