Footnote: The Corporate Bully

A Software Project

I once wrote an entire suite of bespoke software for a commercial vehicle dealer­ship. 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 electr­onics 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.

The printer was connected to the programmable calculator [the computer] via a parallel interface.

A parallel interface comprises an 8-bit data bus [a parallel byte for a print character], a Strobe signal wire for the computer to indicate to the printer that a new character is available, an ACK [acknowlegement signal for the printer to acknowledge to the computer that it has finished reading the newly available character and a Ready signal for the printer to indicate to the computer that it is ready to accept more data [another byte].

It is well known within the IT industry, among hardware technicians and program­mers alike, that whenever a printer randomly fails to execute carriage-return/line-feed commands, it is because one or more of the 3 control signals — Strobe, ACK or Ready — is not being received. This is usually due to one or more of the 3 respect­ive signal wires not having been connected or having come loose or broken.

Lazy technicians in a hurry will often just set the timing of how frequently a char­acter is sent by the computer on the assumption that the printer will be able to keep up with it. But this is bad practice. It was immediately obvious to me that this was probably the reason for the problem with the system in this case.

The connector at the printer end of the interface cable was industry standard. All signals were connected and implemented. The arrangement of signals at the 'com­puter' end were not. And I wasn't privi to the proprietary information necessary in order to know which signals were which. So I could not just get my soldering iron and connect them fully. I suspected that the problem was at this end.

I explained all this to the 'technicians' but I was met with a wall of ignorance. They didn't seem to have a clue what I was talking about. Otherwise the problem could have been fixed there and them.

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 manu­fac­turer'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.

Incompetent 'Engineers'

Then it finally dawned on me. This large manufacturer's so-called customer engin­eers 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 com­ponents. 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 tele­vision 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.

I Had to Do 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 pos­sible 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 perman­ently resident subroutines. That is why the calculator had a built in hard­ware sub­routine 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 pro­gram out­putted 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 'ready' signal from the industry standard interface on the printer. The manu­facturer'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 ac­counts report program was a stream of text followed by a set of figures. The line ended with a carriage-return/line-feed [CR/LF] sequence. The print interface ROM on the calculator sent the text through all right. However, it had to shunt the fig­ures through 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 inter­face did not wait long enough for its subroutine to finish passing it the con­verted numbers. It sent the CR/LF sequence too early. Consequently CR/LF 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 some­times! 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 am­ount 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 prob­lem and that I would have to contact another company who now handled such prob­lems, presumably on behalf of the manufacturer. Notwithstanding, he also said I would have to pay this company.

I should not rightly have to do this. The manufacturer had sold to me a system that it is responsible for making work according to its published specification, which it did not. Consequently, the cost of making it do so is rightly the responsibility of that manufacturer.

But I had no choice. I was between a rock and a hard place. My customer's business was suffering and a 6 month project had escalated to 18 months.

I contacted this other company and it sent two so-called 'engineers'. They turned out to be two of the manufacturer's original employees who had set up on their own to­gether with two other former employees of the manufacturer. They were simply TV repair men who blindingly obviously knew nothing about data processing syst­ems. 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.

Legal Proceedings

Nevertheless, I still received an astronomical bill from this other company for the non-work they had done. I justifiably refused to pay for two reasons:

1. The system's ability to function according to its published specification was clearly that of the manufacturer, so it was the manufacturer's responsibility to get it working properly.

2. The manufacturer had held out this other company as having the necessary and sufficient skills to fix the brand new system I had bought directly from the manufacturer. It was obvious that this other company was incompetent and incapable of resolving the problem.

Notwithstanding, this other company took out a High Court writ against me for non-payment. This was obviously the brain child of its managing director [also an ex-employee of the Japanese corporation], who seemed to be the only non-technical member of the company. He came across to me as a very nasty piece of work in­deed. In fact, somebody else, who also developed and installed systems based on this corporation's products had previously warmed me about him.

So 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 new company formed by these ex-TV repair men.

All I had asked for from the beginning, and paid for in full, was a brand new stand­ard system which this manufacturer was selling, that would work according to its pub­lished 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 strings. I passed all my numeric out­put 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 suc­cess­ful.

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 who­ever 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 recom­pense 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. Under UK law, a career as a criminal would have been a lot safer for me.

So a High Court battle was precipitated by an unconnected wire in a printer cable! And all because a multinational corporation couldn't muster a technician who knew the workings of an industry standard printer interface. This multinational corpora­tion never resolved the problem, which would have been quick and easy for them. Instead, I had to spend vast amounts of my own time circumventing their problem through extra software, which almost doubled the size of the total program package due to the machine's small overlay memory size.

This is one of three deadly legal situations I had to navigate with devastating and wholly undeserved loss during my 15 years in business. Business, as an economic process, stinks.

---

Parent Document | ©May 1998 Robert John Morton