Clockwork factories

Computing science is failing its students and drastic measures are needed to remedy the problem, Darrell Ince argues.

Most of our computing departments should be closed down and their staff dispersed to other, existing departments. That is my view. My argument is mainly educational; however, there are also good research reasons for such a diaspora. The main reason for my suggestion is one of success: computer science has burgeoned over the past decade to the point where I believe that we are trying to teach too much.

After externally examining many British computer science degrees I have concluded that we as computer science academics are drastically short-changing our students.

The typical British computer science degree will contain a set of necessary courses, usually studied in the first or second year, which prepare the student for the remaining years.

These include courses on programming and the mathematics required for the study of discrete systems. They are often then supplemented by courses that reflect the research interests of the department and by courses that take the degree up to the standard required for professional accreditation by one of the engineering institutions.

A student on a typical British computer science degree might also study courses on: the theory of computation, a subject full of quite dense mathematics; the human-computer interface, informed by cognitive psychology; project management, based on the latest trends in management science; and artificial intelligence, which is usually a heady mix of software development and hard, almost mechanistic, cognitive psychology.

This is quite a change from 20 years ago, when programming and the study of software systems were the main things taught under the guise of computer science. This huge melange is also reflected in British research. I recently browsed through three main computing journals looking for British work. I discovered papers which described the use of certain sociological theories in understanding a complex air traffic control system, the use of sophisticated appraisal mechanisms for the evaluation of human-computer systems, the application of soft systems theory in the development of computer systems, the design of a novel programming language, the use of mathematical notations in the specification of highly parallel systems, and the presentation of novel programs for the display of three-dimensional scenes on a two-dimensional computer screen.

This has happened because of success: we now know much more about computer systems than we did 20 years ago - although I would say that we still do not know how to apply our knowledge. Such a large dimension to the subject of computing brings many problems.

The main problem is that we do not have the teaching time to look in depth at important topics. Probably the best example of this is software engineering: the subject that tries to apply conventional engineering methods to the development of large software systems. This is often taught as a second year course with only time to carry out an abbreviated tour of a huge subject. This provides the student with a fleeting acquaintance with important topics such as design, and usually provides no acquaintance with important areas such as the role of the software department within an organisation.

Such a surface introduction to a subject is more dangerous than not teaching it at all, because the messages it gives are of necessity simple. A typical software engineering course gives students the impression that the solution is more tools, project support environments and better development methods, and that total correctness of a system is the target in system development. These messages lead to all sorts of problems.

My university allows me to carry out some consultancy provided I take holidays to do it. This consultancy has involved me in examining the software health of companies and making recommendations, or acting as an expert witness when a poor system is delivered to a customer. Most failures I have seen have not been technical ones but are attributable to poor management or a poor interface with the rest of the company.

Many of the successful companies I visit use only a little technology. They often have a quality system which is not too restrictive. What they do have - and this is not taught in any software engineering course that I know of - is a management policy which assumes that their development staff will be creative and attempts to interpret their management responsibilities by supporting the creative act. Those companies which have heavy quality regimes, where staff must subjugate themselves to software tools, usually have some degree of moderate success. But even in times of recession they have major problems in staff turnover.

Another message for which there is no time on courses is that the software development department has to act in concert with a number of other departments to achieve success. Two of the most important are the quality assurance and the marketing departments.

I have spoken to computing graduates who have been surprised that an increasing number of quality assurance departments have a proactive role and, in getting away from the old pinstripe and clipboard image, have almost become a support function.

The career of a computing graduate can be affected greatly by the competence of the marketing department: a good one, which aggressively seeks out new work that is technically feasible, usually results in a successful company. A poor marketing department which is unsuccessful in seeking out work, or promises anything to a customer for a fixed price, almost invariably leads to major financial problems.

The final point is the role of total correctness. There are systems that require total correctness: nuclear power control, railway signalling and aircraft navigation are good examples of these.

However, there are systems where the main imperative is speed of delivery. Many financial systems have to be developed in a climate of extreme competition, where the first bank or finance house that gets a system to support some financial product takes a large part of the market. Usually a system that is just about correct, but which can be delivered quickly, is far superior to a system that is totally correct but late. Such a message does not get through to our students on software engineering courses because the lecturer is too busy teaching tools and development methods - paradoxically those very methods which result in correct systems being developed over far too long a time period. These are some of the problems that occur on a typical software engineering course on a computing degree. I have drawn from this area because it is the one I know best. I am sure experts in other areas could give other instances, for example, the lack of time to explain many of the influences that the various branches of psychology have had on the design of the human-computer interface.

Not only does the size of the curriculum inhibit a deeper understanding of the topics taught on a computer science degree course. It also prevents important topics being taught at all. Probably the best example of this is the fact that communication studies are still only taught as part of a computer science degree scheme in a very small number of institutions. What is remarkable about many of the successful computing companies I see is that the staff who rise to the top have relatively low-level technical skills; what often distinguishes them from their more technically clued-up contemporaries is their ability to communicate: to present, to write a report or produce a snappy presentation.

What this often means is that the computer scientists who only have technical skills and rudimentary communications skills become a form of underclass only good for the development of software systems. The overall impression I get from these problems is that there does not seem to be a culture in many of our computer science departments: there is no feeling, for example, as to whether a department is an engineering department or a science department.

My solution would be to split up our computing departments. Staff who teach and research subjects concerned with software artefacts that are strategic tools for a company would be best off in a business school or a management department. Those who feel that their area of expertise is software engineering would function efficiently in electronic or electrical engineering departments. Those who see the subject as primarily theoretical would become a lively addition to our diminishing mathematics departments.

Some of this is happening in an evolutionary way, mainly in the area of commercial data processing, where business schools with computing expertise and information systems departments co-exist with computer science departments. From such a diaspora would emerge degree schemes which would be a welcome expansion of the hurried, fragmentary courses that computing academics have to teach in a crowded curriculum.

The fragmentation of computer science departments would, I believe, have a beneficial effect on the subject not only in teaching but also in research. For theoretical computer scientists this would mean that their work would be judged by the high standards of the mathematics community.

The British theoretical computer science community suffers from a number of research problems. This is best exhibited in some of the community's journals. Often the papers in these journals give rise to small mathematical results -usually after an interminable number of pages of concrete mathematics.

The standards of a mathematics department would at least provide an impetus to improve the presentational side of research. The best mathematical papers are succinct, do not rely on a surfeit of concrete mathematics and clearly signpost the significance of the results they present. At best it would lead to some notion of research significance for the results of the research of theoretical computer scientists. For the computer scientist who regards his or her work as oriented towards engineering I would say the research advantages of moving into an engineering department are even larger. Electronic engineers produce power circuits that dissipate less heat than current circuits, interface chips that have a higher transmission rate than previous chips, and pattern recognition systems that recognise patterns more quickly and accurately. If you examine a British software journal you will see a different focus. There will be little validation carried out in engineering terms. Whole journals are published in which not even a qualitative appraisal is given of material presented.

More serious is that the focus of these journals is not on software products and applications, but on the processes used to create software. Our software journals often publish whole issues on new software tools, development methods and techniques without discussion of products.

There is a good reason why some of our software engineering research should address these issues. Developing a software system is an immensely complex process; however, this is no excuse for almost wholly ignoring the traditional concerns of other engineering disciplines.

When I write newspaper articles on technical subjects in computing, I often have to resort to such devices as metaphor, simile, the selective use of facts and the use of high levels of abstraction to get over an idea.

I often feel that I am overusing these devices and effectively telling lies to get a complex message across. At this point I usually abandon the article. I am now getting the same feeling about our computing degrees: that they are at such a high level of abstraction and so selective that we are on the verge of conveying a large number of false ideas about the subject and effectively telling our students lies from which they may never recover.

Darrell Ince is professor of computing science at the Open University.