3.2 - ICT 1900 Range Software – The Start

 

The following is extracts from the talk “Developing Software for the 1900 “ that Peter Hunt gave at the London 1900 Seminar in May 1996:

 

“In late autumn 1964 I was asked by Arthur Humphreys to take charge of the production of the software for the 1900 computer range. On reflection, I am not sure the word "software" was used: nowadays that's what it would be called.

At the time I was Head of the Bracknell Laboratories running several interesting hardware and software projects, with large penalty clauses. I had about 12 years programming experience, and had learnt the hard way that software projects were easy to conceive but difficult to implement, were invariably late on delivery and usually exceeded budget.

I asked what software had been promised for 1900, and was given a copy of a document — I think it was document number 1024 — which listed what would be available and by when on the hardware of the 1900 as it was envisaged at that time. I have never found out who wrote the document. It was a phenomenal list of software on various configurations including all types of different peripheral equipment.

After reflection, I decided that I would only accept the appointment under certain conditions:

• I would be allowed to revise document 1024 with more appropriate delivery dates;

• I would be given the appropriate resources to do the job, including adequate competent experienced programmers, and adequate com­puter hardware facilities under my own control on which to develop the software; and

• that I report directly to Arthur Humphreys (so that I could be sure that if I had problems they would hopefully be sorted out quickly without going through layers of management!).

 

 

Arthur accepted these conditions, and then the real work began.

First, I rewrote document 1024 and reissued it with more realistic de­livery dates. This was not difficult in itself, but it did involve re-educating the sales force, which had been working with the previous edition. I had to spend time in meetings with senior members of the sales force, and give lectures to the junior members, assuring them that the new dates would be kept, and that there would be no further slippages during the lifetime of the project.

Second, we started work immediately on recruiting 100 programmers.

Third, it was arranged that the necessary hardware would be delivered to "Programming Division" (as we were then known). This included every model of processor and at least one of every type of peripheral that was likely to be delivered to customers.

 

 

I organised the production effort into a number of divisions responsible for specific software areas:

• Operating Systems

• Compilers (scientific and commercial)

• General Purpose Software (eg Plan assembler language, housekeeping software)

• Applications Programs

• Services (including supply of computer time, quality assurance and issue of software)

 

So there were five divisional managers. I met them every Monday morn­ing to sort out problems and to consider progress on all matters.

At the time, software engineering was either non-existent or in its in­fancy. The divisional managers decided how each of their projects should be organised, how they would be implemented (there was no BS standard in use) and how they would monitor progress against the promised dates (Pert was in fact one of the applications programs we were implementing).

 

One of the aspects of the project that worried me most was the problems that might arise when we started to issue all this software to customers all over the world. The originating programmers would have tested it to the best of their ability but, as we all knew, the software would still contain bugs when issued. We wanted these reduced to a minimum.

 

We therefore set up a primitive quality assurance group. Its task was to take software from the production divisions once they said it was ready for release and, using only the documentation available to customers (we had a separate group, not reporting to me, of technical authors producing manuals and user guides), to use the package as fully as possible, imitating as far as they could the day-to-day usage by customers.

When they discovered errors, the package was referred back to the originating division for correction. The quality assurance team then re-tested the corrected package, and this iterative process continued until the team was satisfied with its correctness. Only then was the software released.

 

It was not long before 1900s were being delivered in quantity all over the world, and the software distribution system had then to be organised properly.

We decided to issue the software on magnetic tape as the general rule. This meant we had to have fallback arrangements for those installations which did not have magnetic tape transports, such as the 1900s which used cassette tape.

 

Once issued each software package had to be supported, as we would now put it. When a customer reported an alleged error, this call (or more likely a letter) would be dealt with initially by a front line support force in another division (not reporting to me). This was because in many cases the customer simply needed assistance in the use of the package.

When the support team thought the customer had discovered a genuine error they referred it to us. We investigated and reported back. If it turned out to be an error on our part a "software notice" would be issued to all customers with the following information:

1. description of error;

2. when it would be corrected (release number and date due);

3. what to do in the meantime.

This all seems very standard today, with our modern help lines, but 30 years ago we were breaking completely new ground.

 

I was particularly pleased when, in 1968, ICT was awarded the Queen's Award to Industry for Technical Innovation. (Many people asked me what was the technical innovation - my reply was simply that we actually produced some software, and supported it, and that most of what we promised was on time.) I must add that the Award covered not only the software work for which I was responsible, but also all of the Executive work carried out at Stevenage and West Gorton.

It has never failed to amaze me that here we were in a highly technically difficult interface with three groups of programmers working in three separate locations - West Gorton on large systems, Stevenage on small systems and ourselves in Putney producing software for both - and I did not once have to sort out any difficulties with the interface with the Executive teams. Full marks to the Compatibility Committee under the chairmanship of Bruce Paterson.”