Stability

The issue of stability is very important if the system is to be large and to have a long life expectancy. The problem is similar to that of advanced operating systems: the developers and their staff want things to be better, current, and as sophisticated and clever as possible; programmers want a completely stable interface (this is especially true of those amateur users who write a little code to add one small facility to the system to make it perfect for their purposes). Users also believe that they want commands and results that are predictable: what worked last year should work today in exactly the same way. On the other hand, they also want the programs, algorithms, functional capabilities, and data to reflect last month's journal article. Of course, no one but developers sees incompatibilities among these objectives.

An obvious possibility is to make a rule that a routine, once installed under a particular name, has the same behaviour forever, and that new things or versions of things must have new names. This is an easier approach to apply to a subroutine library - especially a subroutine library from which users are permitted to copy and imbed "obsolete" routines that have been replaced by newer ones with different names' - than to a major integrated collection, where such an approach requires a great deal of discipline on the part of the maintainers and tolerance on the part of the users. Unless the architectural and linkage problems have been solved exceptionally well, the accumulation of semi-obsolete codes will also cause degradation and high disk costs much sooner than if the growth of the system resulted from an extension and replacement strategy alone.

While the stress here has been on programs rather than on data, the problems with data are quite similar. The ability to reproduce an old result may require that the associated data be retained forever (or nearly so), even when it has been found to be out of data or substandard. There have been a few cases in which users have rather carefully built procedures to compensate for data inadequacies that they were aware of, only to have their procedures produce seriously incorrect answers when the original data values were replaced with "corrected" ones. There are strong arguments for being able to associate particular vintages of data with particular analyses or studies, but such requirements impose great difficulties on the system's design and its human managers. So the data and program problems are not very much different after all.