One of the unforeseen areas where Agar is of some interest is in terms of base development methodology. In an attempt to maximize user feedback in terms of bug-reports and interface design, Agar has been regularly deployed on the UCR CS department servers since September of 2003, and pushed as a useful tool to the TAs regularly during the ensuing period. All told, Agar has gone through no fewer than 15 iterations of deployment (on average, a new release at least every other week). In essence, we are using our local collection of users (drawn from the instructors and TAs) as testers throughout the process.
A number of factors contributed to such a rapid development cycle being possible. The most major of these being the choice of development platform. Agar is developed using wxPython [4], the wxWidgets [5] bindings for the Python [20] programming language. One of the major benefits of using Python is its very loose run-time type system, which allows for very rapid development and tactical changes. wxPython adds powerful GUI support in this same vein, granting simple development of advanced features. For example, the original addition of Drag-and-Drop support for moving Tools from the Toolbox into the Rubric took on the order of 20 lines of code for the base functionality. More traditional development platforms (C++, Java) could have easily had 7,000 lines (the size of the base project, not counting Tools) of GUI code, to say nothing of the functionality that is required to make such a large system work. Just as Agar is intended to be an enabling technology for graders, wxPython is an enabling technology for building GUI applications of this sort.
Additionally, a number of factors contributed to this style of development being necessary. First and foremost was the fact that nobody could enumerate the majority of use cases for this project before development began. Certain features, such as a simple Tool interface and the ``write-once'' Comment system were known before beginning, and it was known that some form of submission identification system would be needed, but the majority of the Tools themselves, as well as the usage of Agar for grading written work, could not have been predicted a priori.
In essence, development on Agar was a variant on the Extreme Programming (XP) [1] methodology in terms of planning, deployment, and redesign. Release cycles were very short. Features were only attempted when it was felt they were understood enough to make a complete implementation of them before the next release6.1. Only a single developer was working on Agar for the majority of its lifespan to date, so simplicity was highlighted: it is far better to have something that works for most cases and satisfy the user than to delay the release in order to deal with esoteric situations that will likely never arise. This was not, however, full XP development. Rather than having a single client, development responded to the needs and whims of all of Agar's users at once. Rather than have a well-designed testing plan throughout, features were added in the most easily available fashion possible, which was later discovered to violate the layering of interface from functionality, making XP-style automated testing intractable.