We’re about to kick off another summer of work on Hippo, our baby-SourceForge for student use. I’m pretty excited: five good students will be working on it full-time, on five brand new machines (thanks to a donation from the Jonah Group), starting from a freshly-refactored version of Trac that includes Christopher Lenz’s new component architecture.
The biggest challenge we face this summer may lie in trying to add some sort of requirements management tool to Trac. The reason is the sheer size of the gulf between what textbooks teach, and what developers actually do. For forty years (if not longer), academic researchers have been saying, “Formalize! Formalize!” For just as long, students have nodded, jumped through whatever hoops they had to in order to get a good grade, and then gone out into industry and done something else. In the twenty-three years I’ve been programming for a living, I’ve only twice seen anyone write the kind of specs I see in software engineering textbooks; both times, it was to satisfy a contractual requirement, and both times, the spec gathered dust once the real work started.
There are several possible explanations for this situation. The first is to say that formalization is the right solution—most programmers may be too stupid/too lazy/too conservative to see it, but it will inevitably triumph in the end. Having heard advocates of Scheme and proletarian revolution make the same claims, I’m disinclined to believe any of them any longer.
The second explanation is to say that we’re just not teaching it the right way: we don’t introduce early enough, we don’t explain it well enough, it isn’t integral to other courses (in the way that calculus is in math and physics), and so on. I don’t buy this either, and the reason I don’t is that the people who teach at colleges and universities are, by and large, a pretty smart bunch. If they believed that formalizing requirements would help students with assignments, they’d do it, but how often do you see instructors write use cases, or draw sequence diagrams, as part of assignment handouts in courses on compilers, graphics, or operating systems?
What I think we’re going to try to build this summer (as always, we reserve the right to change our minds) is the requirements equivalent of DrJava. If you haven’t seen it, DrJava is an entry-level IDE for Java programmers; it isn’t nearly as powerful as Eclipse, but it isn’t nearly as intimidating, either. As a result, students are more likely to realize that yes, it does help them. Once that happens, they’re more likely to believe that investing time in something more complex will pay off.
Over the next four months, we’re going to try to figure out what “DrRequirements” would look like, i.e., what should go into (and be left out of) a tool that instructors can use to specify requirements for programming assignments, and/or students can use to specify what their solutions actually do. In order to qualify as a solution, it must be possible for both parties to learn the tool from a single hour-long lecture (which is all we give tools like Subversion and JUnit). More importantly, both sides must see real benefit to themselves from using it: as our experience with bug tracking systems shows, anything that appears “write-only” from a student point of view will only be used under duress.
One possibility (pulled out of thin air) would be something that made bidirectional connections between the assignment spec and students’ test cases, i.e., something that allowed students to say, “Tests A, B, and C are proof that part 3.1 of the assignment has been done,” and to then check which parts of the assignment spec hadn’t been satisfied. We’ve kicked a few other ideas around too, but are still looking for one that has that “Ah ha!” feeling to it. If you have any ideas or pointers, I’m easy to reach.