5.1.3 Continuation
In changing educational computing environments of today, a danger is that as soon
as a project becomes "finished", its maintenance may become neglected, so that it
quickly falls from disuse to "unusability." Unfortunately, faculty who conceptualize
courseware may have a predisposition for viewing courseware endeavors within the
framework of publications like textbooks. These beliefs are counter productive,
or fatal to projects in changing distributed computing environments:
The interest of the faculty is in the initial development of the
educational software, not in its ongoing maintenance. The expectation is that
once the software is written it should continue to run indefinitely.
The computational model of networked workstations with its tendency to change
has far different implications than a personal computer where the operating
system can be frozen forever. (Stewart, 1989, p. 302)
One factor that appears to help protect projects from deterioration is the degree
to which computing organizations chose to adopt a role of active involvement
in maintenance. One example of where this role was recognized and filled is
in the current Athena computing organization, which includes among its goals
the hope of helping the faculty produce maintainable software as well as watch
over the software once it created. This role was elaborated in a conversation
with Schmidt (personal interview, March 4, 1992):
Schmidt: Sometimes these things have to be ported, and during that
process you have to make little modifications because things are written with
a specific system in mind. And so the source code needs to be available,
because you can't use just the binaries. We need the source code. We are
also trying to help faculty members get their source code in good working order.
Some of these programs are huge, so it is important to use standard software
engineering techniques. You have Make files and you organize your directories
in certain ways, and when you revise software, there's a system called Revision
Control System (RCS), where if you make a change it records the change, it says
who does get it and when, and the changes are made so you can back them out.
Another thing that is valuable is that only one copy of any file needs to be
around on a central file system, so that even when a faculty member goes away
we know where the source code is stored.
If the computing organization does not provide support for software maintenance,
then the courseware project must provide for its own continuation. One factor
that contributed to continuity from within the project was the degree of orientation
or socialization provided between changes in the team. An example of where this
took place successfully was in the Physical Geology Tutor Project (P. Kinnicutt,
personal interview, October 1, 1992).
Kinnicutt: I didn't have any formal training on how to develop
portable code. I did my own reading, a C book, Portable C. I read that,
and several other books. It does make life easier in the long run.
Hopper: Are you responsible for training the next person to be aware of
portability issues? Is this something that can be communicated, or is it
something you can only learn through experience.
Kinnicutt: I think it's something that can be communicated, but I think
it's best communicated by looking at examples of other people's code.