Remember the saying that you should never go back into the kitchen of your favourite restaurant? Well the same description probably applies to the computer rooms housing the hardware and software systems of many organisations. They're usually a mess of various computers, wires and parts.

Take that mess and picture the software running the computers spread throughout a large corporate office. Many of those systems can be labelled as a "Big Ball of Mud'', a "haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle'' that predominates in software architecture according to Brian Foote and Joseph Yoder of the University of Illinois' Department of Computer Science.

"We've all seen them,'' they write in a research paper. "These systems show unmistakable signs of unregulated growth, and repeated, expedient repair.

Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition.'' Sound familiar to those of you who've had to stop work when the system crashes? While the research paper deals mostly with programming, I'll hazard a reasonably informed guess that the same sort of analysis can apply to the information technology departments in many companies.

Executives should worry about such issues as a "big ball of mud'' ultimately drives away good programmers and entrenches the power of the ones left behind, who then become the only people to know the system well enough to keep it running. They, in a sense, become masters of the mud, they state.

And instead of concentrating at improving the computer system and ultimately the efficiency of the organisation, the programmers end up fixing crisis after crisis to keep the data flowing.

"Programmers with a shred of architectural sensibility shun these quagmires,'' Mr. Foote and Mr. Yoder write. "Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.'' One cause of a mess is the use of "throwaway code'', software that was written quickly for a particular purpose with the intention it would be discarded. Unfortunately the code behind the software ends up becoming the system, one with a casual structure and without any documentation. A "big ball of mud'' may also grow out of systems that are added to in a piecemeal fashion over time.

"As with a decaying neighbourhood, a downward spiral ensues. Since the system becomes harder and harder to understand, maintenance becomes more expensive, and more difficult,'' they state.

Information technology workers are driven to create such systems because they are not given enough time or resources to design the software architecture for the long term good of the organisation. In turn the organisation is often driven to move fast because it must get a product to market before its competitors, the two researchers state.

As the programming mess develops the "swamp guides become more valuable than architects'' in the organisation. "...Architects depart in futility, while engineers who have mastered the muddy details of the system they have built in their images prevail. They become indispensable.'' The solution to such a mess is not "rigid, totalitarian, top-down design'' they state. Software systems must be developed according to function. While that's a lofty goal in any systems development often the opposite occurs and complexity increases to the point at which the organisation's programmers or IT professional can cope. At this stage "simple repairs become all day affairs as the code turns to mud''.

One solution is to constantly review the software solutions and code being written for an organisation. In translation this means constantly reviewing a company's computer network to see where it has grown. Only then can you begin to fight back the weeds and reclaim the system for the business ends for which it was designed. Another solution is to have programmers or IT people work side by side on each project, thus allowing for constant peer review. This strategy also ensures someone else in the organisation knows the system.

Still the authors lament that the messy code, "bloatware'' (see Word 2000, new versions of Netscape and Microsoft Explorer for examples), and sprawling systems type of architecture will continue to dominate the world of computing.

"People build big balls of mud because they work,'' they state. "In many domains, they are the only things that have been shown to work. Indeed, they work where loftier approaches have yet to demonstrate that they can.'' While I think this view is probably true I also believe this unfortunate situation is allowed to continue in many organisations by technophobic executives who are too afraid to properly assess the direction their information technology workers are taking in developing the business. You can read the full paper at http://www.laputan.org/mud/mud.html.

The increasing spread of computer viruses, like the "Love Bug'' that infected corporate systems worldwide last week, shows just how important e-mail has become to the corporate world. A study by Messaging Online predicts that by the end of next year there will be one billion e-mailboxes worldwide. During 1999 the number of electronic mailboxes jumped 84 percent to about 570 million. The average corporate user owns about 1.5 mailboxes while the average Internet-connected household has four, according to the study.