In the late 1980's I was working in the computer department of the Civic Hospital in Ottawa as they were rolling out a new hospital patient-management package. The major problems with the new package was: it was American, necessitating the education of American programmers and re-writing large sections of code; and, it was obsolete even before the hospital bought it. I've mentioned before that the source code that ran most of our banks, governments, and similar large institutions was written in the early to mid-1070's using the tools available at the time. That meant: COBOL (COmmon Business- Oriented Language).
COBOL was originally designed in 1959 and underwent major redesigns in 1960, 1974, and 1985. One of its main draw-backs, especially from today's vantage point, was that it was overly-verbose and lacked the ability to perform some common programming tasks such as recursion, handle memory allocation issues (eg., "local" variables versus "global" variables, as well as dynamic assignment of variables), and, in general, was not designed for structured programming. In other words, it, much like BASIC, another common language of the time, encouraged "spaghetti code." The term spaghetti code referred to programs that did not adhere to consistent construction and architecture. In other words, the logic of the flow of the code was missing, often resulting in a haphazard mess very difficult to maintain and debug. I ran across quite a few samples of this kind of writing in my early consulting years which resulted in my becoming somewhat anal about programming standards in my own work, and in the work of any employees that I supervised.
In any case, the new code that was being rolled out at the Civic Hospital was a disaster from the beginning and a number of senior information technology heads rolled once the extent of the disaster was clear. My observation was that the entire process was flawed. I mentioned before that decisions about computing were rarely based on logic and analysis. In this case, they bought this particular package over a Canadian-designed one because it was backed by a large American corporation (McDonnell-Douglas, to be exact). At least, that was the only reason I was ever given.
I think part of the problem was that when computers moved into the business world in a big way during the 1970's there simply were not enough people experienced in the field, especially at the management level. Prior to that computing was the reserve of scientists. I quickly learned during my first ten years or so in the field that I much preferred working with scientists over office management, because scientists, as a rule, no matter what their field, understood that computers were no more than tools and were as dependent on the skill of the user as any other tool. Consider the case of a hammer being used by a skilled construction worker versus a novice who has rarely touched one. The novices, in this case, were the office workers whose expectations of computing far exceeded the ability of the machines at that time to deliver. Emotional relationships with the machines became inevitable in the magical-thinking world of the technologically illiterate. Machines became stupid and willfully uncooperative when they failed to meet the expectations of the users. I still see those attitudes in the work-place today despite our 40-plus years experience at this point.
(A prime example of this from within the last two years: a fellow employee was trying to enter data in the wrong field on her screen. Instead of stopping to think about why the machine was rejecting her input, she kept typing the data over and over again, growing more and more frustrated. She got so emotionally wound up that I had to tell her, several times, more firmly and loudly each time, to stop what she was doing before I could point her to the correct area to enter her data.)
I don't recall all the highly embarrassing events that unfolded when the Civic's new program was rolled out into production mode. One that stood out vividly was that when visitors to the hospital inquired at an information desk about the whereabouts of their loved one, if the patient had been moved from one room to another they were reported to be deceased. Very fertile ground for serious lawsuits, indeed. But I was involved in the technical side and so that's where I saw most of the program's shortcomings.
To give a detailed example. Hospitals distribute plastic identity cards to their patients. These cards are almost invariably embossed (raised lettering) so that they can be run through simple carbon-pressure machines to take an image of them. This helps enormously in tracking and identifying patients. The machines that produce these cards are called embossers and they are usually placed strategically throughout a hospital at the various points where patients enter the system. An admitting clerk types the information into a computer screen and the program directs the required information to an embosser to produce the card. This is all very much like sending information to a printer to produce a form or a letter on paper.
There are standard ways to control the flow of information to a device like a printer, or, in this case, an embosser. The computer needs to know when the device is ready to start receiving data and when the computer should wait before sending more--or if the computer should resend the data because the receiving device missed or otherwise detected an error in the data already sent. At the heart of the control matter are two characters called ACK and NAK. When a device has received seemingly error-free data it returns an ASCII character called an ACK (short for acknowledge), indicating it is ready to receive more; the code for this character is 06. If the device needs data to be resent, it returns a NAK (short for not acknowledged), ASCII character code 15(Hex), or 21(Decimal). This all is a process called flow control. Think of an airplane pilot saying "Roger that" or "Say again" to the control tower. If the pilot instead said, "Okay," or "What?" chances are pretty good that he would be misunderstood. That's why we use code words, or code characters.
As soon as the new program went live and patients started being admitted to the hospital all the embossers failed. They produced garbled output if they produced anything at all. Desperate phone calls with the American support team finally lead to the person who developed the code. How did you manage flow control? he was asked--a fairly astute question considering the panic. Oh, I used ACK and NAK, he replied. So, if flow control is not the problem, what else could it be?
And then the network boys tapped into a line to trace what was actually going to and from the embossers. They did not see ASCII codes 06 and 15. What they did see were strings of 41-43-4B and 4E-41-4B. And what do those codes translate to? You probably guessed it: the alphabet characters A-C-K and N-A-K. And that was the sort of incompetence that lay at the heart of the shinning new management package.
The pressure, frustration, disappointment, and desperation throughout the computer department was starting to affect my health and, when an opportunity elsewhere presented itself, I jumped at it--just before the big axe fell on those responsible.
No comments:
Post a Comment