Craig.Everhart@CMU-CS-A@sri-unix.UUCP (07/28/83)
Response to the blinded Robustness mailbox has been good, but not
quite good enough to do the trick. If you have a robustness-related
story or a change log for a program, wouldn't you consider sending it
to my collection? Thanks very much!
What I need is descriptions of robustness features--designs or fixes
that have made programs meet their users' expectations better, beyond
bug fixing. E.g.:
- An automatic error recovery routine is a robustness feature,
since the user (or client) doesn't then have to recover by
hand.
- A command language that requires typing more for a dangerous
command, or supports undoing, is more robust than one that
has neither feature, since each makes it harder for the user
to get in trouble.
There are many more possibilities. Anything where a system
doesn't meet user expectations because of incomplete or ill-advised
design is fair game.
Your stories will be used to validate my PhD thesis at CMU, which is
an attempt to build a discrimination net that will aid system
designers and maintainers in improving their designs and programs.
All stories will be properly credited in the thesis.
Please send a description of the problem, including an idea of the
task and what was going wrong (or what might have gone wrong) and a
description of the design or fix that handled the problem. Or, if you
know of a program change log and would be available to answer a
question or two on it, please send it. I'll extract the reports from
it.
Please send stories and logs to Robustness@CMU-CS-A. Send queries
about the whole process to Everhart@CMU-CS-A. I appreciate it--thank
you!