1st October 1997I've been watching the Millennium debate in the IT world with a growing sense of unease. As you may remember, my earlier thoughts were that it would not amount to very much; certainly not for banks and similar financial institutions. I still think that's largely true but my confidence is lessening daily.
The problem is that no one can really get their brains around the full scope and dimension of what's required, not the actual work itself. The worst part is that computer chips are now all pervasive. Can you think of an electrical gizmo that certainly doesn't have a chip? Think about office equipment, photocopiers, fax machines, printers... You may not be aware that the machine is date-sensitive but are you absolutely positive? Cocksure enough to assure the World Chief President of your employing company? It sounds silly buy in fact it's very real. Imagine getting into work on January 3rd 2000 with all IT systems running sweet as a nut but no-one can copy, fax or print? The company would be in deep trouble.
Maybe that's why the mayor of New York has issued a warning about services in the city come 2000. About 50% he reckons, for up to three months. Some services worse for longer. So that's things like rubbish, payrolling, employees, benefit payments, street lights, oh and traffic lights. Of course, New York is a technically backward place, isn't it? It might just be a politician covering his back, but it's pause for thought. An equally worthy body this side of the pond has declared London will suffer worse because there is no one organisation in charge of the whole city.
So, while Megamammon Plc is making sure its photocopiers are "Millennium compliant", resource is being drawn away from ensuring the time-critical systems on its chemical works are going to function, that the data received over the wire is compliant, and that all systems interfacing it are up to scratch. As ever, the hard pressed company IT development/testing department is pushed into third or fourth place behind pressing corporate concerns; like being able to fax out the first completed Times crossword of the new millennium.
Of course, this is how the problem very largely arose in the first place. In the old days of the 1970s, there were two basic truths to corporate IT; one, that computers were fabulously large and expensive and two, a program written today was unlikely to be around in ten years' time. It is the first truth which concerns us most.
Because the machine was so expensive, it was always entirely consumed with production runs, there was no time in the day for a code compile or a test run, and data storage room was equally rare. In this environment, there was just no scope for hit and hope development. So Johnny Programmer desk-checked the logical flow until he got what he wanted, wrote the program out on coding sheets, took it to be manually punched onto machine readable cards, took those deck of cards (without dropping them or mixing the order in any way) to the machine room and left them there for a compiler run. With a bit of luck, maybe next week.
Any decent program worth its salt will not compile first time, and our hero would in due course find himself presented with a returned deck and something like a memory dump to find out where he went wrong, a couple of days after he last thought about it. Remember, computers were the stuff of sci-fi and everything about them was outrageously pricey. Hence the paucity of machine development time, and basic editing and debugging tools. In such a situation, anything that could be simplified would be. It is far easier to process a two figure year than a four figure year and that is what happened. It wasn't going to matter, these programs would never still be used in twenty-five years...and they aren't.
What happened was these "solid as a rock routines" (They were built to last because no one could test them again) were perpetuated from system to system as utility programs ever more deeply buried in the bowels of increasingly large and complex systems. The programs can be quite recent, but they will call date routines copied from programs that are ancient.
So there you are. Don't blame IT, blame the management that brought you Red Robbo. The good news is, and it's not that good really, the people who wrote these programs are still around as senior managers and directors - and are often the only ones who have the old language skills to check the program code. They are, to say the least, out of practice.
Pretty horrific? No. Just wait until Megamammon Plc realises it has to get people off checking the fax machine and on to getting the financial systems ready for monetary union. That's when you'll hear about it.
My tip for the next century? Pull the sheets right up tight!
Christopher Chadwick, EUG #34
