I must admit I hadn't thought too much about this issue before, but I now recognize its importance. This is an advantage of this form of discourse.
[quoting Fyte, 30 Oct 96] ...students have very high expectations of a piece of IMM and will get very upset if there are gremlins in the program, whereas if it was a benchtop practical they would expect that it wouldn't always work perfectly.
[quoting Anonymous, 1 Oct 96] You usually only get one chance to get something right. If you deliver something that is not quite right, then it really does not matter for a very long time what you do to repair design flaws, fix bugs, etc., The end user's expectations have usually been dashed. It may even be better in some cases to start again rather than overcome the resistance associated with using something that has had bad comments made about it in the past. Students are quite good about passing the word along about things that do not work from term to term: "Oh those sessions were really awful, I wouldn't bother going if I was you as the software never worked."
The Drug Dosage project highlighted in the initial essay suffered from a similar problem. Here, it wasn't the student as much as the staff who were reluctant to use the program. The serendipitous pregnancy of the content expert meant that other staff had to take over management of the use of the program. They and the tutors were very uncomfortable with computers, and didn't really WANT to be using them. When the tests didn't work and a crop of other problems surfaced, they understandably had a real bad feeling about the program. They were stuck with a group of students doing a test on a computer program which didn't work, and which they didn't have the faintest idea of how to fix!
Even fixing the bugs didn't redeem the situation--the damage had been done. We had meetings with the Head of Department to try to resolve the issues, and the program was withdrawn from use. The program had to be internally redesigned to remove the problems, and large parts of it reprogrammed. Eventually, it was reinstated in classroom use, after rigorous testing (see below). We also had to reassure the tutors about how it would work, etc. The program is in use again, and the tutors are now happy and positive about its use.
Another related issue is that many content experts have not appreciated how difficult it is to debug an IMM program. Their experience is in print material, and the analogy they draw is with proofreading. Debugging an IMM program is orders of magnitude more difficult than finding typos. When you fix a typo, you don't cause a number of other typos to appear at seemingly random locations in the typescript, but this is what can and does happen in software.
In many of our earlier projects, too little attention was paid to testing. We would be merrily developing, when the content expert would arrive and ask how progress was going, because the students were due to use the program in two weeks. Even worse, their assumption was that the program would work flawlessly first time, and didn't need to be tested. On at least two occasions, the program went straight from the programmer at midnight on Sunday into the student lab at 9 a.m. on Monday, without having been trialed by anybody. Then it was our fault as developers that students were unhappy with the program not working!
That's why we use project management now!
Perhaps poor user expectations come from poor expectations of the content expert.