Developing the e-scape software system

Most innovations have contextual pre-cursors that prompt new ways of thinking and in their turn help to give form to the new reality. This was the case with the e-scape software development process. The origins of the system existed in software components and ideas that we had developed through previous projects, but the ultimate direction we took with e-scape evolved through a sometimes scary but always fascinating collaboration with TERU at Goldsmiths University of London. The literature refers to ‘agile development’ (Highsmith 2002) and it is certainly a good name for the process we undertook with TERU. It is tempting to believe that one can specify a system, agree it with the clients, and then build it. But not so, … or at least not so in this case. We of course did draw up detailed specifications, but as soon as we started to build it, we or the TERU team would see how much better it could be if only we could just …. In the end, understanding of what is required evolves as the understanding of what is possible develops. So specifications morphed from do-able to maybe; from the firm ground of known technologies to the more shaky territory of the half-known and the “I’ve read about that somewhere”. But the underlying reality was always time and money. The system had to work robustly with enough time ahead of the national pilots for the TERU team to do all the necessary trials and training in schools. And it had to be done within fixed costs agreed at the outset. In this paper I outline the principal challenges that we met along the way and summarise our approach to resolving them.