I've often wondered how people with seemingly-serious credentials could publish arcane, cryptic, and sometimes nonsensical pieces on computing matters. Perhaps my question has been answered. There is no legitimate excuse for this paper getting beyond the "circular file."
Stunning. One cannot imagine this occurring in a medical journal. Of course, in my various roles I've seen and heard numerous presentations on IT that are equally as convoluted and unfathomable, as well as IT job descriptions for significant leadership roles in industry that are not very different linguistically than the student's computer-generated "research paper." For example, this recent ad:
Fri Apr 15 09:43:00 PDT 2005
A bunch of computer-generated gibberish masquerading as an academic paper has been accepted at a scientific conference in a victory for pranksters at the Massachusetts Institute of Technology.
Jeremy Stribling said Thursday that he and two fellow MIT graduate students doubted the standards of some academic conferences, so they wrote a computer program to generate research papers complete with nonsensical text, charts and diagrams.
The trio submitted two of the randomly assembled papers to the World Multiconference on Systemics, Cybernetics and Informatics, or WMSCI, which scheduled for July 10-13 in Orlando, Fla.
To their surprise, one of the papers--"Rooter: A Methodology for the Typical Unification of Access Points and Redundancy"--was accepted for presentation.
The prank recalled a 1996 hoax in which New York University physicist Alan Sokal succeeded in getting an entire paper with a mix of truths, falsehoods, nonsequiturs and otherwise meaningless mumbo-jumbo published in the journal Social Text.
Stribling said he and his colleagues only learned about the Social Text affair after submitting their paper.
"Rooter" features such mind-bending gems as: "The model for our heuristic consists of four independent components: simulated annealing, active networks, flexible modalities, and the study of reinforcement learning" and "We implemented our scatter/gather I/O server in Simula-67, augmented with opportunistically pipelined extensions."
... Conference organizers were reviewing their acceptance procedures in light of the hoax.
Director of Research Information Architecture
Job Description: The Director of Research Information Architecture reports into the Senior Director of Research Shared Technologies and Services. In this role, the Director leads a team of architects to define and communicate the vision for information, technical and solutions architectures within the organization.
Working with the Enterprise Architects and functionally-aligned IS groups, the Director will define and implement processes, products, and services that support the agreed vision. This includes compliance and metrics processes, strategic divisional capabilities, new technology evaluation and introduction processes, and the definition and implementation of new shared services. As part of these deliverables, clear business value must be demonstrated through the use of business cases and results reporting.
Qualifications: Bachelor’s degree (or equivalent), and at least 10 years of relevant work experience with a demonstrated record of leadership, knowledge across a number of technology areas, and a business focus. Ability to define, communicate, and obtain agreement, both within the IS groups as well as the business areas, on strategic architectures and processes. Strong skills in business process, information, technology and solution architectures.
One wonders if this semantic blur and linguistic confusion are a cause of IT system failures frequently noted in all fields, including this interesting paper from the government sector: "Governmental Information System Problems and Failures: A Preliminary Review." Public Administration and Management: An Interactive Journal. 1997, Volume 2(3).
Abstract: Enthusiasm over information technology has led to inattention to problems and failures which have characterized many governmental information systems. This paper uses governmental reports, newspaper and periodical accounts, as well as academic literature and qualitative observations to analyze problems, limitations, and failures that are common. This is a preliminary analysis based on an inductive review of available accounts of failures. The purchasing process leads to many failures and is especially difficult in the public sector. The development process is the cause of many information system failures due to poor project management, overwhelming complexity of systems, as well as technical problems. Inadequate training means that government personnel only make use of a fraction of the power of software. Information overload is becoming a problem for which most governmental organizations have no solution. Poor quality of data is present in many cases due to organizational resistance as well as lack of oversight and use. Organizational obstacles to sharing information make sharing difficult despite technical advances in the ability to share. Inadequate payoffs characterize many investments in technology due to lack of use, poor implementation, the marginal role of technology in productivity, and failure to use the technology. In major decisions, digital data systems take a backseat to rich data gathered by executives in informal meetings and discussions.
Sounds quite familiar, with many parallels to clinical information technology failures. Certainly, allowing papers into the IT literature that are reviewed as poorly as Sokal's spoof in the social sciences does not improve the quality of management of IT.
Come to think of it, the "artifically generated paper" the students created sounds much like the presentations of CIO's I knew at various hospitals. The hospital executives were so overwhelmed by their impressive-sounding gibberish, they literally figured the guys must have been geniuses. My clarity in trying to expose the gibberish proved nearly ineffectual for a long time. These CIO's were finally disposed of, only to become CIO's at other hospital systems.
In clinical IT, when you don't understand what the "IT guys" are telling you about why the system they expect you to be dependent upon in patient care can't do this or won't do that, don't assume it's because you're "only a doctor." Ask a lot of questions.