The past years, the work I have done in the field of GIS is getting closer and closer to the roots I have in software development. Is it just my own experience or is the world around us changing?
When I starting my professional career it was with a hydraulic engineering company. I worked with the software department and developed applications to support flood early warning and flood damage assessment. After some years I started creating these applications using ESRI’s Arc/INFO (is it was spelled at the time), ArcView, and ArcIMS.
I remember a Saturday evening when a colleague and I were enjoying lasagna while working through lengthy pieces of SQL trying to figure out why the web application we developed did not return the desired result for the selected location. One of us was coding the thoughts the other came up with combined with his own ideas and interpretation. The problem had been bugging our development team for a while and as the deadline came closer we resorted to this extreme measure.
By midnight the problem was solved and we sat down with a beer and reflected on how the approach we took proved successful and whether or not that could be turned into more practical use. It appeared that the concept of ‘paired programming’ we practiced was one of the elements of a software development methodology call eXtreme Programming (XP, not to be confused with that recent addition to the existing family of operating systems).
That experience made me realize that developing a GIS application successfully depends on well-known software development principles just as much as any other non-GIS software projects. The fact that we started off with products that deliver a lot of functionality out-of-the-box does not change this.
It may even complicate things. Whatever development methodology is applied (RAD, DSDM, XP, Waterfall, RUP), an application goes through the process of design, coding, testing in different cycles of different lengths. But the final step to success always is user acceptance. When starting from a commercial-off-the-shelf product that is being customized, there will always be discussions when anomalies are found as to whether this is part of the customization and thus within responsibility of the developer or is part of the off-the-shelf product and thus within responsibility of the manufacturer.
The fact that this discussion takes place at the end of the project when budget is running out and both developer and client want the product to be finished, but working, adds to the complexity. An idea may be to introduce a second type of acceptance test, this time aimed at the developer! Whatever off-the-shelf product, data or document is supplied to the developer is subjected to an intake test and anomalies are noted and either accepted to exist or lead to modification of the supplied item.
And guess what? Formal acceptance of items delivered to the software team at the starting point of the project or during the project, was one of the things we introduced at this hydraulic engineering company when we started thinking about Software Quality Assurance; nothing new, but still refreshing in a way.
So after some years my interest in software development has been revitalized and I now again read about subjects as software process improvement and test process improvement and how these may contribute to the success of our GIS projects and thus to the success of our clients. And the success of our clients is our primary concern.
Appeared in GeoInformatics Magazine (http://www.geoinformatics.com) in June 2002
