Where the bugs are

As I write this column in the middle of winter, a couple of things take me  back to summer camp, where all I could count on was lack of sleep, bad food, bugs, more bad food, and more bugs. As I mentioned last week, we are implementing a new content management system, a mammoth project that means at least a few late nights and snack-machine dinners (see "Mac meets world"). As with any complex system, even the best-laid plans can go awry when unanticipated technology bugs arise, even with well-vetted products. On the surface, it would seem that the only solution to preventing delays would be to allow more time in your schedule to integrate your system. More time to complete a task is always a good thing; however, even experienced chief technologists can be surprised in the final days of a rollout. When you are working with systems that are made up of off-the-shelf components, you never know what walls you might hit.

Free IT resource Hear how top CIOs turn change into a competitive advantage. Sponsored by HP Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Back in December, I wrote about the concept introduced to me by Hal Varian, dean of the University of California at Berkeley 's school of Information Management and Systems, of recombinant growth, which refers to reassembling existing technologies into something novel, innovative, and ultimately greater than the sum of its parts. This is the invigorating side of technology — combining wireless applications with Web services, for example, can yield exciting results. This week, I have experienced the downside of combining technologies in unique ways — the sum of the bugginess in a system can be far greater than the bugs in the individual products that comprise it, and often exponentially.

At InfoWorld we are implementing a solid, proven content management system that we checked out exhaustively before  purchasing. The system as we implemented depended on a few things, at least superficially: on the back end, an app server and a database; on the front end, a word processor and a web browser. Simple enough?

Unfortunately not, and it had nothing to do with the quality of the product we chose. Although the promise of Web services technologies rides on their loosely-coupled nature, specifically their OS and programming language independence, the truth of implementing technology in the real world is that the people involved are tightly coupled to existing sets of front-end technology tools that are often personalized, and that can make integration difficult. In a sterile environment, the content management system we are implementing makes sense and works well. But our environment is not sterile, and yours probably isn't  either. In one case, an end-user couldn't execute a piece of our application within Internet Explorer, and after banging our heads against the problem, we came across a similar problem (thanks Google!), which indicated that a mapping program on her machine was conflicting with our application. The easy answer would be to make all of our users' machines alike by locking down their PCs to prevent them from doing things like installing unauthorized software . But as CTO of a media company populated with technology journalists covering bleeding edge technology, how would I ever get away with that? Running a pristine PC environment, while ideal from an IT management standpoint, sometimes just isn't possible within the context of a real business.

I'm looking forward to the launch of front-end products like Office 11 that will offer loosely-coupled access to data on the back end for programatic manipulation by more centrally controlled processes.

I'm just wondering what the bugs might be. Ultimately I'll have to put it in front of real users in a real environment to find out.