How ICL came to axe the CODIL project

On the 3^rd of May 1968 John Aris, who had worked on Leo Computers, was then Manager of Applied Systems in English Electric Computers, and later Director of the National Computer Centre wrote: about a new research project called DORIS (later renamed CODIL):

DORIS, a 'Data ORiented Information System', is an original and radically new; approach to the systems/programming of computers, devised by Dr. C. Reynolds of this Department. It involves holding a large proportion of the decision-making logic, normally built into user programs, as part of the data files, and analyzing it not with a variety of special applications programs, but with one general purpose decision making routine. If this proves viable it could result in the virtual demise of the conventional application program in many fields, replacing it by the said general purpose routine and groups of calculation routines. Its data structure, being closer to the ordinary modes of human thought than computer files generally are, could allow the ultimate user far greater freedom to use the computer as an information handler in a familiar way, and without the need for expensive commercial programmers. This would, among other advantages, ease the implementation of management information systems. A further important consequence could be a new approach to CPU design.

Despite the fact that the experimental research program that had been set up to test the idea achieved all its goals, showing that the idea actually worked, the project was unceremoniously dropped two years later following the merger to form International Computers Ltd. As principal investigator, who was given permission to follow up the idea in a university environment, I have extensive files on the project – but these lack some of the managerial assessments that must have taken place before the project was originally supported, and also leading to the final closure. I was therefore interested to discover that folder 1/89 in the J M M Pinkerton section of the ICL archives in the Science Museum Library at Swindon dealt with the project.

In fact the folder proved to be very thin, and, for instance, does not even include the six design documents which supported the original proposals or the draft report that became the basis of the Computer Journal paper CODIL: The CODIL language and its interpreter. It is perhaps relevant that this report was written to describe the software when closure seemed a possibility, in a way that would not embarrass ICL by making extensive general claims on publication, and the implications of the idea, as described by John Aris, were not dwelt on in any detail.

While most of the documents were either written by me, or I had seen them at the time there were two single page documents relevant to the decision to close the project. In September 1969 Basil de Ferranti (who was clearly interested in systems which in some way modeled the brain) sent the following letter to P. D. Hall and L. Lightstone with copies to P. V. Ellis, J. M. M. Pinkerton, J. Meredith Smith and A. C. D Haley.

One of the significant projects which was under way at Minerva Road, and which came to the Research Department originally from the E[nglish] E[lectric] sales side, was based on a new approach to modularising customer software.

Called CODIL the technique has won a number of supporters and would appear to be not only a useful product in certain well defined areas, such as product distribution centres, but also to carry an underlying principle which could be applied in many areas. The key figure in the development of CODIL was Dr. Reynolds and the question is really whether or not we wish to retain his services. Clearly if there is merit in CODIL we would wish to but if the company doesn't wish to take it up I think it improbable that he would wish to stay.

Perhaps you would like to take advice on this matter and let me know what further action we might take.

Basil de Ferranti had been Managing Director of ICT before the merger but had been "demoted" to Research Director, with no responsibility for the New Range (later 2900 series) computers at the time of the merger. He left the company not long afterwards, and his pivotal position in UK computing in the 1960s hardly get a mention in many of the accounts of his career. I suspect that his letter was treated as non-urgent by the recipients, as the problem of the project and my employment were really Basil's problem at a time when the company was in turmoil trying to cope with the effects of the merger. What I guess happened is that nothing was done until it became urgent to make a decision because I was still there and the old Research Division which managed me had been closed! I guess that at the end of January 1970 an urgent request (not on file) was sent out for an assessment. As a result the following two assessments were hurriedly written on a single page early in February, possibly using the recently written draft report. I have no idea who the authors were or what their status was within ICL (except that they were probably with ICT before the merger). Definitely the authors did not contact me for clarification on any point, or allow me a chance to comment on what they had written.

Report by G. C. Sibthorpe – dated 4^th February 1970

Although I am not very familiar with CODIL^[1] it appears to me to have one major disadvantage over similar languages such as SPECOL^[2].

CODIL imposes its own file organisation on a set of structured data ^[3] and could not, therefore, be used to interrogate existing files. SPECOL on the other hand enables a data structure to be superimposed upon conventionally organised files. The data structure in this case is a set of parameters to the interpreter^[4].

Since CODIL, like SPECOL, at present only processes files sequentially^[5] I cannot see users taking the trouble to set files up (which cannot yet be amended)^[6] for the rather doubtful benefits that it offers^[7]. This would particularly apply if PEARL^[8] (or something similar) is just around the corner!

[1] I doubt that he had had any contact with CODIL apart from reading a single document describing it – definitely there was no technical contact with me on the subject. The opening words read like management speak for “I haven't the vaguest – but as you insist on a report pretty damn quick I will write one without bothering to spend much time on it.”

[2] CODIL was a general-purpose language optimised to automatically process poorly structured information for a very wide range of tasks in a human friendly way. SPECOL was a specialised information retrieval package designed by a Civil Service user to search arrays of well-structured data generated by other packages. To treat CODIL and SPECOL as similar is about as inappropriate as comparing the compiler of the then popular programming language COBOL with one specialist component of a payroll package and complaining that the COBOL compiler doesn't do payroll!

[3] He has totally missed the point that CODIL is specifically aimed at tasks where it is, in part at least, difficult to design conventionally structured files. In conventional systems at the time (including SPECOL) a data field could only contain a single value. In CODIL the equivalent “structure” would represent a single value, a list, a range, negation (i.e that the DISEASE was NOT “Smallpox”) or ANY or NONE. He is so concerned with retrieval from well-structured files that he overlooks the extremely flexible and novel storage facilities CODIL provides automatically.

[4] He is commenting on the “pilot program” which was a research tool written to explore the system's ability to handle a wide range of tasks which might be difficult to handle conventional computing techniques. To CODIL a conventional well-structured file is equivalent to a CODIL file in which every statement has the same structure and it would been have a straight-forward task to add a parameter driven interface to handle the searching of conventional files if it was decided to produce a commercial package. He is shooting at imaginary obstacles. (To be fair, a 1970s all singing and dancing CODIL commercial software package would have been slow compared with a conventional package if only used for 100% conventional applications on 100% conventional files.)

[5] Of course there were limitations in the “pilot program” as it was only designed to research the idea. While testing was done in batch mode (the only computer facilities available to me) all was set up to simulate online use. Part of the original design involved simulating associative addressing, and indexing was a key element of the earlier sales accounting proposals which depended on rapid processing of files involving some 5,000 product lines and some 250,000 customers. Current research (2011) suggest the approach could easily be modified to work on a neural net. The idea that anyone should want to use CODIL in batch mode if terminals were available had a very low priority in the design philosophy, which was to give the user direct, hands on, control.

[6] The CODIL software in 1970 was only designed to be a research testbed!!!

[7] Virtually all data processing tasks at the time (and most now) are based on the assumption that all the data that matters can be squeezed into pre-designed fixed sized boxes called records. This means that the resulting systems work best at handling highly repetitive predicable data manipulation tasks. But in the real world the key problems are often the “exceptions” which were not anticipated and which will not fit in the predefined boxes. CODIL is designed to allow people to work with computers on tasks which fall “outside the box.” The writer has clearly never thought of the problem “what is it that conventional computer systems find difficult or impossible?” which is the question that led to CODIL.

[8] PEARL was developed at Cornel University, starting in 1968 and the approach was described as constructive mathematics. I was unaware of the work at the time and a quick look at some of the later papers suggest that it was aimed at the sophisticated academic mathematician working within the conventional stored program philosophy. I can see no reason for comparing it with the CODIL approach., which is aimed at helping real people (not academic mathematicians) to work online with complex and somewhat unpredictable real world tasks.

Report by A. F. Besley, dated 6^th February 1970

This is similar in concept to the "CANTOR"^[9] system (which I think has now been abandoned). Such a technique would be of value on 3rd generation machines, but maybe the architecture of 4th generation machines will mitigate the need (being better orientated for commercial, multiaccess data processing)^[10].

Re recommendations, I think the results should be published as I believe there are many other groups beavering away at developing such a processing technique (besides CANTOR I know that Bull GE also are). The CODIL project has achieved some practical results and I am sure we would loose nothing by airing these in an article. Field trials might be difficult to organise - unless N/R^[11] believe there will be a need for CODIL type processing - do not recommend. The other recommendations should be reconsidered after any article has been published, dependant on the interest aroused^[12].

[9] Georg Cantor was a mathematician who made some major advances in set theory. His name has been used in a number of systems, and I was unable to identify the CANTOR system described here. However I suspect that, like PEARL, that this CANTOR was aimed at providing better formal pre-definitions of the task from the point of view of the mathematician, rather that as a tool for helping the average human being to work symbiotically with open-ended tasks.]

[10] The CODIL pilot program was run in batch mode, using punched card input, because that was the nature of the facilities provided for the research. In fact most if not all tests were run as if the system was being run as if from a glass teletype – which was the kind of terminal available at the time. I was also well aware of the problems of running large commercial multi-access databases as I had come from plans related to Shell Mex & BP first online invoicing system and I had written the English Electric Computers marketing guide on the subject. I never seriously considered the idea would be viable on anything but 4^th generation multi-access systems.

[11] = New Range. One of the policy decisions made by ICL management was that virtually all research and development should be directed towards the New Range – later 2900 series – computers.

[12] If one accepts that Beasley did not really understand the novelty of the system, or that limitations were due to the fact that the software was only intended to be a research testbed, one cannot really argue with his recommendations – at a time when not being accepted by the New Range team effectively meant no support.]

Conclusions

What happened was that the English Electric Computers Research Division at Minerva Road was being closed, and while staff that had worked there supported the research they were either leaving ICL as fast as they could, or were being re-allocated to new duties. For historical reason I worked at Computer House, Euston, rather than Minerva Road, and when Minerva Road was closed I ended up without any proper management – although for a time I technically was transferred for management purposes to come under someone in Stevenage who I only ever met once. This was at a time when the innovative “Basic Language Machine” project at Stevenage was being axed.

While Basil de Ferranti may well have liked the idea, I very much get the opinion that his ability to assess new research was not considered significant at Board level. At one stage he asked me to prepare a Board level presentation. Not one director,turned up, and only one sent a representative from what, it turned out, was an irrelevant background. I was seen as a problem because I was drawing a salary from no properly authorised research budget, while no-one had time, in the confusion of the changes following the merger, to do a proper assessment. I am sure that to top management all that was needed was a negative assessment and a lot of short term problems could be immediately solved. So why bother to carry out a proper assessment when it is clear that CODIL was not yet a “market-ready” package.

It is interesting to note that about a month before I was finally kicked out I got an invitation to present my ideas to an ICL research group in Bracknell. I had not even known the group existed, and they had only just heard about what I had been doing. My presentation, given a few days before I left, was technically very well received and it was clear that (1) the research team had never been asked to assess the project, and (2) that they were horrified that it had been axed.

========

For a brief introduction to the political and commercial background to the merger to form ICL in 1968 it is useful to look at the paper ICL: Taming the R&D Beast by Martin Campbell-Kelly.