Predicting 50 Years of Compiler Research -- They Can't Be Serious

Reference: Hall, M., Padua, D., and Pingali, K. (2009). Compiler Research: The Next 50 Years, Communications of the ACM 52:2, 60-67.

I was amused to read the title of the CACM article referenced above. One can't quibble with the tag line -- "research and education in compiler technology is [sic] more important than ever." The article starts out well enough, recounting the past 50 years of compiler advances and noting that in the coming decade, research into compiling for multi-core processing and security and reliability will be major challenges. And it's hard to critique the authors' agenda for the compiler community except that it's rather vanilla and based on current conditions and those easily foreseeable for the near future, such as the need to address parallel architectures. But, it's completely unreasonable to expect that anyone can predict now what our needs will be in 50 years. For example, it seems likely that we will need compilers for quantum computing, yet this possibility is not raised. It's also quite likely, especially if you believe Ray Kurzweil, that by then computers rather than people will be building software, implying an entirely different model for the role of people, if at all, in compiler creation.

Yet Another TAM Article

Reference: Chin, W.W., Johnson, N, Schwartz, A. (2008), A fast form approach to measuring technology acceptance and other constructs, MIS Quarterly 32:4, 687-703.

I'm sure I'm not the only one who's tired of reading articles about the Technology Acceptance Model (TAM). As noted by the authors, there were 698 citations of TAM by 2003 in the Science Citation Index, and fully 10% of the total publications in the IS field prior to 2003 could be classified as TAM studies. There may have been a bit of a drop off in the percentage of publications addressing TAM since 2003, but it always surprises me that TAM articles continue to be published (often in top journals). How can there be anything new to say about it after all this time?

But, there are always exceptions. Don't let TAM fatigue dissuade you from reading this article. It is less about TAM and more about using semantic differential scales instead of Likert scales for IS research. The authors demonstrate that, at least in this case, semantic differential scales are easier and quicker to use, provide an equal degree of construct validity, and produce similar to identical relationships among the constructs measured. This is inspiring. I've always used Likert scales before, but I will seriously consider semantic differential scales in the future. So, for example, instead of asking users to agree or disagree on a 7 point scale with the statement, "Using the system enhances my effectiveness," I will ask users to select among 7 options ranging from "The system is effective" to "The system is ineffective."

RFID vs. Bar Coding

Reference: Hozak, K. and Collier, D.A. (2008) RFID as an enabler of improved manufacturing performance, Decision Sciences 39:4, 859-881.

I always enjoy reading articles with counter-intuitive conclusions or conclusions that attempt to dispel commonly accepted truths about an issue. This one concludes that unless processes are changed, RFID fails to provide much of an operational benefit, if any, over bar coding. Attempts to improve mean flow time and the proportion of transactions that are tardy by reducing lot size, a practice enabled by RFID, could actually have the reverse affect. Very interesting! These conclusions, and several related ones, are based solely on a simulation, which may be suspect, as simplifying conditions are always assumed. Nevertheless, anyone considering RFID adoption should read this. The other caveat, and perhaps the more important one, is that the benefits to improved information and reliability are not considered. I've always thought that the information benefits of RFID outweighed all production metric benefits, so I'm not terribly disturbed by the conclusions. But for those who are considering adopting RFID for the production benefits alone, these conclusions should be kept in mind.

Thoughts on Technostress

Reference: Ragu-Nathan, T.S., Tarafdar, M., Ragu-Nathan, B.S. and Tu, Q. (2008) The consequences of technostress for end users in organizations: Conceptual development and empirical validation, Information Systems Research 19:4, 417-433.

It seems that "technostress" has entered the technical (and perhaps, everyday) lexicon. I'm glad to know there's a word to express what I've been feeling for years. There are times when I feel chained to my computer, when there are not enough hours in the day simply to answer my email. The need for triage always makes me anxious, as my to-do list gets longer and longer. But, I really don't know if it would be any different without electronic communication. The electronic communication simply adds to the immediacy and makes the stress more evident.

The article is interesting from a management perspective because it identifies factors that create and inhibit technostress. Although managers in many organizations can manipulate them to some degree, I wish I could control any of them myself. Unfortunately, that doesn't seem to be the case. For the record, the authors find that technostress is created by techno-overload, techo-insecurity, techno-invasion (how it intrudes into your personal life), techno-uncertainty, and techno-complexity. Technostress is diminished by the provision of technical support, literacy facilitation, and involvement facilitation (the involvement of end users in the technological choices made by their organization).

I was really amazed by the finding that technostress decreased with age. This seems totally counterintuitive. Younger people are supposed to be completely comfortable with technology, and it should not cause them much stress. The authors argue that their finding could be due to the fact that older people are just more comfortable in their jobs, with their tenure softening any stress that they might otherwise feel. I don't buy it, but I have no other explanation.