The need for an improved approach

There has been very little work to date in the area of improving computer science research as it is conducted in a university environment.

In 1950 Turing said (in reference to the Turing test) "the problem is mainly one of programming. Advances in engineering will have to be made too" (Turing, 1950). He goes on to suggest that machines are fast enough and have enough memory to do the task but the problem "is to find out how to program these machines to play the game" (Turing, 1950). While the existence of the "essential" problem is plainly stated, Turing also hints at some of the other problems. He suggest that, based on his own personal rate of coding, "about sixty workers, working steadily through the fifty years might accomplish the job, if nothing went into the waste-paper basket" (Turing, 1950). The first problem is one of people. Coordinating sixty people is no small task. His second is time, fifty years steady work (from multiple people) is unrealistic no matter how noble the task. The most serious problem however is that of the estimates being based on faultless code. Turing sums up by suggesting that "some more expeditious method seems desirable" (Turing, 1950). This is in effect a suggestion that a new method be sought, as programming the machine directly would be almost impossible. This is in fact where Turing takes his discussion.

Machine learning, and the possibility of either training a machine as one would a child or teaching the machine abstract skills such as playing chess, take up the rest of his paper. It seems, however, a fair argument that if the "how to program" question can be answered, then the difficulties involved can be reduced, and Turing's estimates scaled down appropriately. It should be noted that, as Turing was already assuming perfect code, methods of software engineering that reduce errors (while vital) do not affect the estimate. What is needed is smarter coding, a process that allows programs to be written in a way that minimizes the time it takes to code. Given the speed gains made over the last fifty-plus years and Turing's assertion that the speeds of his day were acceptable, we can afford to add some degree of overhead and minimize the coding time at the expense of the running time. If we can do this for any "how to program" problem, we must necessarily improve the rate at which we do research and as a result make solvable some of those problems previously impractical to solve. Turing clearly saw the problems writing a large program would cause, and he mentions a need for further engineering, but what he may not have seen was that the rate at which he coded was a fact of a world made up of his own ideas and that of a machine of his own making. Understood this way, "how to program" is the question of how to create the perfect world with the perfect artifact, people, software environment and procedures.

The Turing-complete artifact (a modern computer) is at our disposal. What we need are the people, and a way of clearly expressing their ideas and communicating them across space and time. Given telepathy, as Turing notes (Turing, 1950), we may have no need for the imitation game. Telepathy could from his description be seen as nothing more than perfect communication, that is both noiseless and complete. This then should be our aim for improving the people: select the best researchers and help them effectively communicate across space and time. The software environment is the final vital ingredient. Much work has been done both inside find outside of academia to improve the platform software is built on and with. More is still needed. As Cooke, Gelfond and Urban explain, "if software advances are to keep pace with hardware advances, languages and other software tools must improve the productivity of software engineers" (Cooke, Gelfond and Urban, 2002). These other software tools might include frameworks, design patterns and implementations of algorithms. In short, communication, reuse and professional discipline are the vital tools.

Better procedures for the researchers are also needed to enable them to improve communication, use the right tools and interact most efficiently with the artifact. This is then the task Turing leaves us. "We can only see a short distance ahead, but we can see plenty there that needs to be done" (Turing, 1950).

Another issue is, as Holcombe suggests, that there is a basic problem with our approach to computer science. He says that, for the most part, the current approach to computer science is not scientific. He suggests that to remain relevant computer science must change. His conclusion is that a field of software engineering science may be needed (Holcombe, 2000). In his book Surveying the field of computing, Carl Burch included some ideas Holcombe raised under Burch's definitions of "software systems" and "software engineering" (Burch, 1999). Another idea raised by Holcombe, is that software engineering education is not "academic enough". He means that students are not taught to critically evaluate methods in the field. In an effort to address this he ran a pilot program where student were required to evaluate and critically analyse recent software engineering literature (Holcombe, 1997). A critical approach to software engineering techniques by software engineering and computer science academics is vital, both to increase knowledge of software engineering in academia and to find where and how it may be of use.

Research has also been done that looked at factors of success in environments that share some of the properties of the university environment. For example Fricke and Shenhar (2000) looked at a manufacturing support environment where, as in academia, many research and development projects may actually be going on at once, and using the same resources (Fricke and Shenhar, 2000). In a review of the literature of project management for R&D, Balachandra and Friar draw the conclusion that the success factors of projects vary greatly depending on their environments. They suggest that future research is needed that focuses on specific environments and types of projects (Balachandra and Friar, 1997).

The concept of using software as a means to transfer knowledge among universities and between universities and industry, was the topic of the EDRC conference as previously mentioned. As discussed at the conference, case studies showed that the knowledge transfer required the movement of people (in the role of expert users and trainers) and not just software. The importance of design documentation was also highlighted (Steier et al., 1993).

Computer science is a relatively young field. Like all scientific fields it is still developing and maturing. The incorporation of certain software engineering techniques may be a vital key to the further growth of the field as a structured scientific discipline.

References above can be seen in the Bibliography.