Mashups haunted by past experience

I have lived through re-orgs, outsourcing and off-the-shelf applications being shoehorned into niche markets by over-zealous management. The latest trend in software, though, is for user-generated mashups.

Recently Serena Software announced its user-friendly mashup tool. According to Serena, its tools will "let non-IT staff take care of tedious, line-of-business Office applications". I screamed. Serena is not the only IT vendor to make such noises.

Initially this sounds like a good idea - why shouldn't users be allowed to take charge of the "day to day" hassles, and short circuit the development process, leaving the IT staff to tackle really big projects?

The problem is, these pieces of code will make their way around an organization and while that can be good in some cases, inevitably pieces of unmonitored, unapproved code will be passed around from user to user with disastrous consequences. And, if - and when - something does go wrong, it will be the IT staff who have to go in and fix the problem. So much for easing the burden on IT.

Whether the mashup camp knows it or not, they still need the skills and support of experienced IT staff. Just because you know how to drive a car doesn't make you a race-driver. Neither does being able to do technical drawing qualify you as an architect.

To illustrate my point, let me share two real examples from my own IT experience.

Let's go back to the late 80s where a public-sector teacher got his hands on a programming manual for the language behind the school-automation system deployed in his area's public schools.

Hearing grumblings about the lack of decent library software in the school system, this person read the manual and wrote a piece of software that ultimately served the needs of his school, a DBQ database running on 486 PCs under DOS. Admirable. But now the problems began. His school librarian began to think of changes to the software and the teacher implemented them. Hearing of this system, librarians at other schools acquired copies of this software and began using it.

Pretty soon, the software had made its way around the state - more than 1,000 primary and secondary schools. And then someone phoned the Department of Education's IT help-line for help with the software. Frantic enquiries were made up and down the chain of command trying to figure out where the software had come from, and how it had spread to so many schools.

Eventually, the author was found, questions were answered and a compromise reached: the teacher was pulled from his teaching duties and moved to head office for the maintenance of the library software. The teacher was now folded into the IT team, which meant the maintenance of the software could be properly managed and documented should he ever leave or once he retired. It did mean, though, this one teacher never taught again.

Could this have been avoided? Very likely - the librarian could have contacted the IT department, the teacher could have passed his code to IT staff after it became apparent that it was useful - the points of recovery were there. But because the software was allowed to reach critical mass unchecked, it was too late to rein it in.

Skip forward almost a decade to another school system - a nationwide music academy responsible for overseeing the examinations of musicians and for awarding certificates.