Why Invention and Innovation Diverge

My compliments on the article "One Laptop Per Child: Vision vs. Reality" by Kenneth L. Kraemer et al. (June 2009). It is incredibly valuable for the ACM community to understand the profound difference between invention (which OLPC certainly is as both concept and product) and innovation (the widespread adoption of new mores). How and why political, economic, cultural, and sociological factors influence, if not trump, great ideas, concepts, and products is pertinent with OLPC, especially in light of the project’s public visibility.

MediaX@Stanford University (like the MIT Media Lab) encourages the study of how technological solutions affect individuals, organizations, and institutions. We especially encourage small research projects, like OLPC, that pursue "grand ideas" through experimental discovery. Last fall, we hosted Kentaro Toyama, lab director of Microsoft Research India, on "Computing for Socio-Economic Development" in which he described work prompted by a student at Stanford’s Center for Innovative Education. Toyama’s lab bought and placed several hundred XO laptop computers in Bangalore elementary schools, encouraging students to take them home per Nicholas Negroponte’s hope of inspiring parental involvement. To his dismay, many of the machines were stolen and put on the black market where they were worth six months of discretionary family income and clearly too much of a temptation.

The lab concluded that a mouse, at $2 each, had useful attributes: worth nothing on the black market without the XO, could have initials carved onto it without affecting its operation, and inexpensive enough for educators to buy. The Microsoft team designed a "mouse docking station" that could accommodate up to 10 mice, color-coding each cursor on screen so students would require far fewer machines. Despite initial worry that the students would be confused by the multiple cursors, experiments found no particular difficulty with this new operating mode.

Learning could now truly begin. Working in classrooms much larger than those in the U.S., Bangalore’s teachers are seldom able to help individual students even if they get stuck, though classmates quickly recognize when their fellow students need help and come to their aid. An early discovery with the XO was that students mastered arithmetic in one-third the time and retained vocabulary drills far longer. Research also found that boys, as well as girls, begin to exhibit cooperative rather than competitive behavior in games and problem-solving sessions on the machines.

Microsoft Labs built a simple reference model—MultiPoint, available as a software development kit—that has since been adapted for teachers in the U.S. and anecdotally found to have similar educational value (http://www.microsoft.com/unlimitedpotential/TransformingEducation/MultiPoint.mspx).

MediaX researchers often find analogous dichotomies between designer functionality and the intended user community at a more systemic level than those usually considered by HCI designers. These techniques, coupled with Kraemer et al.’s excellent coverage, provide additional skills and approaches to the ACM design community.

Charles House (past president of ACM),
Stanford, CA

Technologists have a moral duty to ensure that their activities contribute to solving the problems at hand and not diminish other, better, solutions. In this light, the analysis by Kenneth L. Kraemer et al. (June 2009) was helpful in articulating some of the dangers that befall technology projects in sub-Saharan Africa where establishing a vibrant education system in rural areas is a wholly different proposition from its counterpart in urban areas. Schools even a few kilometers from a large town have markedly less-developed infrastructure than those in town. The result is that education often must wait until children are old enough to walk those kilometers to the nearest school.

Try to imagine what OLPC project success would look like in such a context. A typical rural school is constructed with great commitment by the local community but consists of only mud walls, tin roof, and muddy floors. It has a thousand students but no running water, electricity, sanitation, or food service or even enough pens and paper. It is staffed by surprisingly dedicated but inadequately trained, underpaid, and undervalued teachers. Now imagine that the same school receives a large stock of laptops (even if specially designed) that promise a pedagogical revolution. I find such a prospect laughably unrealistic.

It was therefore surprising to read that initial OLPC trials should be conducted in Addis Ababa, the capital of Ethiopia, through a large-scale deployment (50,000 XOs), presumably much of it in rural areas. This imposes on the government an unrealistic expectation to establish a technical-support infrastructure, satellite distribution of digital books, and large-scale teacher-training program. This in a country that invests heavily in improving school enrollment and dramatic university-expansion programs but has difficulty ensuring enough textbooks for its children.

All this is in marked contrast to another initiative emanating from MIT. The online open courseware initiative is well known; less well known is the initiative to put open courseware onto hard drives for distribution to eligible educational institutions with poor Internet connectivity. How helpful it would have been if more MIT professors included adequate reading materials in their open courseware offerings.

OLPC appears to give priority to a technocratic solution to what is essentially a social problem. Technology to support pre-service and in-service teacher education is a much more urgent priority. Incremental advances in technology infrastructure must be used to develop technical skills. That way, the development of teacher and support-technician skills would support future possible large-scale computer deployments.

Imagine how different OLPC implementation would be if it were instead conceived as "one laptop per teacher."

Julian M. Bass,
Addis Ababa, Ethiopia

Refocus Fragmented CS Conference Culture

Moshe Y. Vardi was brave (and absolutely right) in taking on CS conference culture in his Editor’s Letter "Conferences vs. Journals in Computing Research" (May 2009). Consider how a new technique develops: Prof. Fragment has an idea and publishes it at a workshop. Several of his students refine and modify it over the next few years, publishing their work in various conference proceedings. Another of his students identifies a crucial application of the work. Finally, Prof. Fragment gives an invited lecture at a major conference, covering the full story supplemented with compelling empirical evidence. Unfortunately, the lecture is not accompanied by a paper. Now everyone wants to use the powerful new technique, asking Prof. Fragment for permission to spend a sabbatical term with him at Jigsaw University. He is able to accommodate only one old pal, while everyone else makes do with his group’s five conference papers and the online slides of the invited talk. This typically consists of more than 100 pages of material with overlaps, omissions, and contradictions, because each paper represents a different stage of the overall work.

Prof. Fragment would do the CS community a service by publishing his technique in one coherent journal article, presenting the method, together with refinements, applications, and empirical results. But if he were to write such a paper, some referees would likely recommend rejection on the grounds it contained nothing new.

Lawrence C. Paulson,
Cambridge, England

Begin with an Author’s Response to Reviews

We agree with Ken Birman’s and Fred B. Schneider’s Viewpoint "Program Committee Overload in Systems" (May 2009) regarding the shortcomings of the conference-review system. A key factor is the lack of incentives for authors to submit their best possible papers, leading, as Birman and Schneider described it, to yet more submissions, along with larger program committees to accommodate them, overworked volunteer program-committee members, and less-informed decisions, as these members are able to read only a small percentage of all submissions.

To discourage repeated submission of the same manuscript—often unchanged—to many different conferences, we propose a simple solution: require that all conference submissions provide two things:

History. A review history of the submission that includes the previous venues to which it was submitted, along with the submitted versions and the reviews the authors received; and

Summary. An explanation of how the authors addressed the concerns cited in previous reviews.

This approach would allow program committees to build on the expert knowledge of the previous review committees where the level of expertise might have differed from their own. Broadly used, it would reinforce the argument that publishing in a CS conference is like a journal publication in other disciplines. It also means authors are further motivated to address or rebut the concerns cited in previous reviews, resulting in a better understanding of the concerns. Finally, authors would be discouraged from "shopping the paper around" until it meets the bar of a particular program committee, encouraging them instead to prepare an acceptable manuscript before its initial submission.

Though this requires extra work by authors at submission time, that work is worth the benefit ultimately received. The concern that some authors might not disclose previous submissions can be addressed the same way simultaneous submissions are treated—by clearly stating the policy and consequences for violating this trust.

Changing the existing system is not difficult. All it takes is one program-committee chair doing an experiment. If it’s a good idea and works, others will follow. If not, it will get everyone thinking about alternatives. Using an author’s response to reviews is a recent innovation but is already widely used in the CS community.

Jose Nelson Amaral,
Edmonton, Alberta, Canada
Michael Hind,
Yorktown Heights, NY

Name the Field: Computer or Computing

The words we use to describe things profoundly affect how we think about them, and once a term has gained a foothold in a field, changing it and its effects is nearly impossible. An example is Peter J. Denning asking "What is computer science?" in his Viewpoint "Beyond Computational Thinking" (June 2009). It has always seemed strange to me that we call our field "computer science" rather than "computing science," focusing our attention on the hardware and its design and programming rather than on the higher-level great principles that are in fact independent of hardware and historically part of other scientific disciplines.

Perhaps we should change our titles and business cards to read "computing scientist" from "computer scientist" to emphasize this point.

Harry J. Foxwell,
McLean, VA

Author’s Response:

I endorse Foxwell’s view of "computing science." Old names stick when they establish a brand that people generally like. That seems to be the case for "computer science," a name established by the founders of the field in the 1950s. At that time, people in computationally intensive application areas (such as physics and statistics) called what they did "computing science," but the computer scientists of the day felt that "computing" represented applications and not the central focus of R&D. In the 1980s, we began using the term "computing" in place of "computer science and engineering." Twice in ACM history some members proposed calling the organization the Association for Computing, but the required constitutional amendments failed, probably because the voting members liked the long-established brand name. Today, ACM goes by the motto "Advancing Computing as a Science and Profession." We’re getting there.

Peter J. Denning,
Monterey, CA

Back to Top