COMPUTATIONAL TOOLS 115
potential inputs, and combinations of factors, and must be robust even in the face of invalid usage. The
program should have well-understood and bounded resource demands, including memory, input-
output, and processing time.
- Maintenance. When bugs are discovered, they must be tracked, patched, and provided to users.
This often means that the code should be structured for maintainability; for example, Perl, which is
extremely powerful, is often written in a way that is incomprehensible to programmers other than the
author (and often even to the author). Differences in functionality between versions must be docu-
mented carefully. - Documentation. If the program is to be usable by others, all of the functionality must be clearly
documented, including data file formats, configuration options, output formats, and of course program
usage. If the source code of the program is made available (as is often the case with scientific tools), the
code must be documented in such a way that users can check the validity of the implementation as well
as alter it to meet their needs. - User interface. The program must have a user interface, although not necessarily graphical, that is
unambiguous and able to access the full range of functions of the program. It should be easy to use,
difficult to make mistakes, and clear in its instructions and display of state. - System integration and portability. The program must be distributed to users in a convenient way,
and be able to run on different platforms and operating systems in a way that does not interfere with
existing software or system settings. It should be easily configurable and customizable for particular
requirements, and should install easily without access to specialized software, such as nonstandard
compilers. - General. The program should accept a wide selection of data types, including common formats,
units, precisions, ranges, and file sizes. The internal coding interfaces should have precisely defined
syntax and semantics, so that users can easily extend the functionality or integrate it into other tools.
Tool developers address these considerations to varying degrees, and users may initially be more
tolerant of something that is more program than product if the functionality it confers is essential and
unique. Over time, however; such programs will eventually become more product-like because users
will not tolerate significant inconvenience.
Finally, there is an issue of development methodology. A proprietary approach to development can
be adopted for a number of competitive reasons, ranging from the ultimate desire to reap financial
benefit to staying ahead of competing laboratories. Under a proprietary approach, source code for the
tools would be kept private, so that potential competitors would be unable to exploit the code easily for
their own purposes. (Source code is needed to make changes to a program.) An open approach to
development calls for the source code to be publicly available, on the theory that broad community
input strengthens the utility of the tools being made available and better enables one team to build on
another team’s work.