Chapter 4: A Futile Chore
Footnote: Barriers: A Corporate Bully
Computer projects often turn sour. And when they do, it is the independent artisan who invariably is made the scapegoat. He is branded as the obvious cowboy while all the corporate contributors use their power and influence to sustain their impeccable reputations. If only the truth could be known.
A Software Project
I once wrote an entire suite of bespoke software for a commercial vehicle dealership. It was just before the advent of the personal computer. My software was to run on a large programmable calculator manufactured by a very large Japanese electronics company. My software worked. The programmable calculator system did not. The line printer (supplied by the same manufacturer) frequently and randomly ignored line-feed commands. This caused multiple lines of financial accounts to be printed over each other. The resulting printouts (which could be 40 to 50 pages long) were unusable.
A Hardware Fault
The problem was not my software. It was a design fault in the programming of the ROM chip which drove the printer. It was clearly a design fault. I told the manufacturer's so-called engineers the problem. Of course they dismissed it as a fault in my software. After much persistence on my part they finally conceded that it might be a fault in their hardware.
They asked me to check all the voltages on the system's circuit boards. This I did, although it was not my job to do so. I was the software developer who had bought, supposedly, a brand new working system for my customer. The voltages were all correct. There was no malfunction in the hardware. The manufacturer's so-called engineers therefore concluded ipso facto that the fault must be in my software. I tried to explain again that it was not, and that there was a design fault in the printer interface. The engineers I had been dealing with left the company. I was having to explain all over again to new people. I was getting nowhere and my customer still, after many months, did not have a working system.
Then it finally dawned on me. This large manufacturer's so-called customer engineers were not very bright. They seemed unable to grasp the difference between a properly designed system which was dysfunctional due to a component failure, and a system which was dysfunctional due to a fault in the design of one of its components. I found out eventually that all the so-called customer engineers I had been dealing with were in fact repair men. What they were used to repairing were television sets, radios, cassette players and other items of consumer electronics. They were unfamiliar with systems, software or the interfacing of system components.
I was beginning to embarrass the company. The problem travelled upwards to a Japanese engineer based in the UK. He arranged for an identical system comprising the programmable calculator and its printer to be tested in his laboratory. He left it printing for days in order to test it thoroughly. He reported that it printed perfectly and that there was no problem with the system. They replaced the one I had bought with the one he had tested. I loaded my software. The old problem was still there. Both the manufacturer and my customer concluded that the fault must be with my software. I was about to be sued out of existence. I had to find the exact detail of the problem quickly.
Doing Their Job
I deleted all my software from the system and wrote a small program to expedite the computer industry's standard test for line printers. It is called the 'barber pole test'. This test prints each possible character in all possible positions in every possible way across the print line. The design fault was immediately revealed. The interface failed to await the 'ready' signal from the printer after having sent a carriage-return/line-feed sequence. But only in one of two possible circumstances.
In those days memory was very expensive. Consequently computers - particularly the programmable calculators - had very little of it. The model I was using had only 128 14-digit 'words'. There was not much room for squashing in extra little permanently resident subroutines. That is why the calculator had a built in hardware subroutine for converting decimal numbers into strings of characters on the fly just before they were output to the printer. The printer worked fine when the program was outputting actual characters. The problem occurred when the program outputted a number which was passed by the calculator's hardware through this built-in conversion subroutine before being printed.
A Botched Design
I discovered that the large programmable calculator's interface did not recognise the 'busy' signal from the industry standard interface on the printer. The manufacturer's engineers had therefore built in an automatic delay timer which activated whenever a carriage-return/line-feed sequence was outputted. It assumed that the printer would have managed to move its carriage back to the start of the next line by the time the timer had expired. This worked, although it was not exactly a bone fide engineering solution.
However, something else obviously didn't. A typical line of output from my accounts report program was a stream of text followed by a set of figures. The line ended with a carriage-return / line-feed sequence. The print interface ROM on the calculator sent the text through all right. However, it had to shunt the figures though its numeric-to-text conversion subroutine and wait for this to return the string of text characters to pass to the printer. The problem was that the ROM interface did not wait long enough for its subroutine to finish passing it the converted numbers. It sent the carriage-return / line-feed sequence too early. Consequently carriage-return / line-feed got overwritten (obliterated) by the characters of the converted number still coming back from the subroutine. The printer therefore did not advance to a new line. But only sometimes! Not every time. This was definitely a design fault.
I told the manufacturer bluntly what the problem was and that it really was not my job to have to sort out this kind of problem. It transpired that the manufacturer's Japanese engineer had not done a Barber Pole test. He had simply made the printer output exactly the same line of text thousands of times. Characters only. Naturally, with accounting programs, the last thing on the line of a printed report is an amount of money - a number! That is why my programs appeared not to print properly.
Passing The Buck
The manufacturer's sales manager said that his company could not solve the problem and that I would have to contact another company who now handled such problems. He also said I would have to pay this company. I had no choice. My customer's business was suffering and a 6 month project had escalated to 18 months.
I contacted this other company and they sent two 'engineers'. They turned out to be two of the manufacturer's original employees who had set up on their own together with two other former employees of the manufacturer. TV repair men. They fiddled about with the system for almost a week and then gave up. They failed to fix the problem. It was clearly beyond their scope.
Nevertheless, I still received an astronomical bill. I refused to pay. They took out a High Court writ against me. I was now in danger of losing my business, what little working capital I had and my home. Yet it was not my fault. My customer's business was continuing under great difficulty. It was not his fault. The manufacturer had been paid, failed to deliver and was suffering nothing. Neither was the ex-TV repair men's new company.
All I had asked for from the beginning, and paid for in full, was a brand new standard system which this manufacturer was selling which worked according to its published specification. It was a case of might is right.
A Circumventive Solution
I had to get my customer on the air with what was available. I wrote a software subroutine to convert numbers into character stings. I passed all my numeric output through this before sending it to the printer. It all worked fine. However, it meant that all my application programs had to be broken down into much smaller memory overlays and significantly increased the number of disk accesses required as the system was running. Still, the system worked and served my customer well I am told for over 5 years to come. The technical work I had done was entirely successful.
Suffering For Success
Notwithstanding, I had a High Court writ on my hands. The first point to note with this writ is that the plaintiff's solicitors copied the writ on an appalling copier. It was for all practical purposes illegible. It was mailed to me by second class post in a brown window envelope. The address was almost indecipherable. How it eventually got to me is a miracle. It had been delivered to two different similar addresses in my area before it actually reached me. The copy was so bad I decided that if whoever sent it could not be bothered to make a better copy than that then I could not be bothered with it. I forget who I showed it to, but they said that the logo looked as if it was something legal. I therefore took it to my solicitor.
A Devious Ploy
The post mark on the envelope was several days after the date of the writ. This late posting plus the delay caused by the quality of the copy meant that by the time I got it to my solicitor the two weeks allowed for me to respond had expired and judgement was being entered against me. My solicitor objected saying that he would present the illegible copy to the court if the judgement was not set aside and charge the plaintiff's solicitors with obstruction or something. It worked.
Saved But Injured
I then heard very little for about a year. Legal costs had overtaken the full cost of my customer's system. It was becoming silly. Finally, the manufacturer agreed to back down, and pay the other company's bill.
I had done a good job. I had suffered untold stress. Being a lone individual in a fray with a large manufacturer and that other company I had lost all credibility with my customer. They never came back to me for a bigger system when they were due for one. I had done an extra year's work of trying to sort out this trivial problem caused by a large manufacturer's incompetence and negligence. Yet I received no recompense or compensation for this. I had become quite poor. My family was suffering. I was very lucky still to have a home and a business.
Nevertheless, I could not envisage taking legal action against the manufacturer to try to get some compensation for my considerable losses. They could afford the best lawyers available. I could not. I could very easily end up losing everything. The lone artisan simply cannot risk ruination by recourse to law. The law is a weapon in the hands of the mighty with which they are free to exploit and bully the weak as they will.
Parent Document |
©May 1998 Robert John Morton