Initial release of a learning management system at The Correspondence School today will mark a milestone in the practice of extreme programming (XP) in New Zealand. The project is the first major XP development to be done internally — on the premises of the client with close interface with the user community — rather than being "outsourced" and developed substantially independently of its users, says XP coach Bryan Dollery.
The system is designed to plan a sequence of courses for each student, with flexibility as the student learns, and to keep a history of each course unit taken. It permits combination of paper, video, face-to-face and online teaching and tailoring of elements of even the individual lessons to the student’s particular needs.
A full computer-based learning management system like this has never been built before, says chief executive Rod Browning, and there were no models to base it on. This was an important part of the reason for choosing an agile programming technique.
If the school had given the task to developers schooled in a more rigid technique, such as the Rational Unified Process, says CIO Alistair James, it would have taken a lot of time and effort. The developers, moreover, would not be in constant touch with the visionaries (Browning and a small group designing the future education system) and the “pragmatists” at the coalface of teaching, and would have risked taking major wrong directions.
In traditional style “users tell developers ‘the way things work here’ and you end up with a computer-based version of the existing system”, says James. Here the new system started as purely a vision by teaching professionals, who would find it hard to explain to “lay people” — the technically skilled developers. Continual interchange between the two groups was needed to firm the system up gradually.
The XP environment provides that constant interaction. Seven developers sit in changing pairs at dual 21in flat screens (one typically holding the GUI development environment or test screens from the actual application and the other the raw Java code). They develop code to handle tasks or modifications requested by teachers as brief “stories”, each expressed in a single paragraph.
Each “story” carries a degree of difficulty and a rating of its importance. A developer with a particular interest, or currently involved in a particular part of the application, will pick a related “story” and ask for a volunteer to work as partner.
One developer of a pair creates the code and the other “observes”, checking and offering criticism, but the roles can change instantly. If one pauses to think out a knotty problem, and the other sees it first s/he (six of the seven are male) can grab the keyboard and become the active developer.
The code continuously evolves in a series of iterations; if a story is difficult but not important, it might be left to a future iteration.
When each part of the code is completed to the satisfaction of the developer and the teacher that wrote the story, it is put in the repository. Thus there is a production-ready version constantly there. If all the developers came back from lunch to be stricken simultaneously with food poisoning, the application would run in whatever stage it was left, Dollery says.
The system is being developed under J2EE, using a JBoss applications server, with XML databases and JBossMQ as messaging middleware.
The development environment is the Aurora edition of IntelliJ IDEA (intellij.net). The developers take part in the IntelliJ early access programme for exploring new versions of the environment, so the environment itself is being constantly updated with new functionality.
IntelliJ IDEA, Dollery believes, is superior to better-known environments such as Jbuilder.
The learning management system has been developed with an elegant GUI built around panels that can be slid out from the edges of the screen, read or amended and folded away as needed. This is unusual, says Dollery; Java-based GUIs are “usually a bit clunky”.
The system has been under development for only three months, and is ready for its first in-the-field tests. Today it will be released to trainers, who train the teachers. In another two weeks, the production version will be issued to heads of department, while other teachers will get a simulated version to practise on for a while longer.
If a conventional development methodology had been used, James says, “after three months, we’d just about have got the user requirements document done”.