Mashups haunted by past experience
User-generated IT support
With six major offices around the country, countless test centers and hundreds of people on staff, this was not a small organization. A panicked call for IT help was received one day and I - as the resident expert in both the hardware and software language they were using - was sent to investigate.
What I found was a system written in an SQL language that required the users to, at various points, break out of the program to run ad-hoc SQL queries to populate work tables with data for the program to process. And by users, I mean examiners with a keyboard under one hand and an SQL manual gripped in the other.
The system had been written by a staff member who, by the time I arrived, had already retired. Everything was so badly written that the author had been forced before leaving to perform various "housecleaning" tasks by hand on an almost daily basis to keep the system up and running.
We declined to maintain the system and advised the academy to purchase a commercial product - which it did six months later. It meant that they were using a closed-source system, but the software had been properly designed, documented and supported by a company that knew what it was doing.
Some might say this was the bad old days before web services and "open standards". But could any of this have been lessened using the philosophies of Web 2.0 or mashups?
In my opinion: no. For every success story in the free and open source software arena there are a multitude of projects that died through - let's be honest - incompetent coding practices. It's just that you never hear of them, so it's easy to forget these failures exist.
Simply applying a label like "mashup" or Web 2.0 does not suddenly make those involved into super programmers who can deliver the goods on time. A project under any coding philosophy is only as strong as its weakest development team member and mashups allow everybody to be a member.
There will, of course, be those who do know what they are doing and will work in a responsible manner. They may even leave comments on the code that they pass around and leave behind enough documentation that makes maintenance possible. I am not holding my breath, though. The majority will, I fear, fall squarely into the "know enough to be dangerous" category.
Register reader Aubry Thonon is a senior analyst with more than 20-years' experience as a tester, coder, specification writer, team lead, designer and analyst. A regular commenter on Reg stories, Aubry is based in Australia and studying to become a systems architect.