An important issue that is related to our environment is that the Laboratory is not a software production environment. Software is not an end in itself. At the Laboratory, software is mainly written to explore a problem and/or solution. The primary aim of the researcher is generally to gain insight into a physical process. The software is only a means to express and test ideas. Hence much software has a very short lifetime, ranging from a few hours to a few days. Regularly, though, the software developed during research is used for a long time, especially software that has resulted at the end of a research effort. In such a case the software is a vehicle that transports knowledge from the Laboratory to other parts of the company.
Although it might seem that, in such an environment, there is little opportunity for reuse, it has nevertheless been observed that many pieces of functionality are implemented time and again. In our efforts we hope to find ways to locate and capture these pieces.
The software is written by researchers who are experts in their fields, say, physics and chemistry, but who have received little or no training in software development. This has severe repercussions on several aspects of the repository. First of all, we have to limit ourselves in the use of formal languages. We cannot use a formal language, such as Z or predicate calculus, to specify the source text components. Such a formalism would not be understood easily and it would hinder possible reuse severely. Similarly, we cannot use a very formal language to describe designs and properties of data structures and a transformational approach (see e.g.[2]) to software reuse is also not a viable option. In the end it means that we cannot use formal languages the researcher is not familiar with, unless these are supported to the extent that the formal aspects become hardly noticeable.
The fact that experts in the field are generally not experts in software development influences the domain analysis particularly. Experts in the field eloquently explain the technical difficulties they have solved, but are much less able to explain how their solutions are implemented. For example, they could describe a Fortran subroutine by stating that it is needed by another one that computes, say, mixing in a reactor. Moreover, one could say that their translation of the concepts in the domain to objects in the software is often not up to modern software development standards. For example, the concept of abstract data types is unknown to many.
It goes perhaps without saying, that in the Laboratory the researchers do not follow standard, or even common, software development methods. This implies that a great deal of attention must be given to let researchers reuse software. We expect, unless great care is taken, that the ``not-invented-here'' syndrome will be a major problem. The ``Programmers's Viewpoint'' as presented in [10] maps rather too well on researchers in the Laboratory.