October 4, 2010
It is fall and football season in the United States. We are still playing soccer toofootball everywhere elsebut that is another story. American football has long been called a contact sport, meaning the players intentionally collide to move the ball toward the goal line. However, it remains a far cry from rugby, which to my untrained eye seems indistinguishable from unarmed combat.
How, one may wonder, does football relate to technology transfer? For that matter, what do I mean by the phrase "technology transfer" itself? There are broader definitions, but for the sake of discussion, let's define technology transfer as the mechanism via which research ideas are communicated to and adopted by companies and their product groups.
The success or failure of technology transfer depends on many factors, from the personalities and skills of the people involved, through the timing and appropriateness of the offering, to the risks and costs associated with the new idea. No single mechanism is guaranteed to succeed, although there are many mechanisms that are likely to fail.
DANIEL REED: "In the embedding model, researchers become members of the product team, working side by side on the product in the same environment as the product developers."
Opening the technology transfer conversation with a product group by disparaging the current product or questioning the intelligence of the developers is unlikely to create a receptive audience for one's brilliant research result, no matter how scintillating and erudite the subsequent description may be. Nor will woeful obliviousness to the history that led to the current product design, for it is important to understand context and competition. Finally, neither will bad timing. Reporting a better way to engineer a product just before it is finished will accomplish nothing other than depressing the product team, though it may provide guidance for the next product generation.
One needs to build a long-term, productive, and positive relationship between research and product development. It is about creating mutual benefit, sharing the love.
On the positive side, I have observed a continuum of mechanisms that facilitate the transfer of ideas. None is universally successful in isolation, and even in aggregate they may fail. However, the set is far more powerful than the elements, and all can benefit from true contact sport engagement.
Papers. These are the stock and trade of researchers, whether in academia or in government or corporate research laboratories. Yes, members of many product groups read research papers, but an abstract idea, even with supporting experimental data, is rarely the catalyst for uptake of a new idea. A well-written paper does, however, provide the technical details needed when an idea is ultimately adopted.
Demonstrations. These are the "science fair" instantiations of ideas, the early instances that are little more than mockups of the idea. They work on limited data, are constructed using laboratory rather than product components, and they are unreliable at best. However, their virtue is in allowing non-researchers to see and experience the idea in concrete form. Often, seeing really is believing, and a prototype can be convincing in ways that a paper is not.
Prototypes. Prototypes are the next stage, where the demonstration is sufficiently robust that it can be used routinely by individuals and groups other than the creators. The robustness allows product groups and developers to test the idea in more realistic conditions and contexts, and see how it fares relative to existing technologies.
Near Products. Near products are products in all but name, suitable for shipment with little more than cosmetic changes. Creating a near product can be effective if the product team is interested and willing but understaffed, or if they lack the specific technical skills needed to create a product-quality instance of the idea.
Papers, demonstrations, prototypes, and near products help, and they may sometimes be sufficient to transfer an idea into a product. However, they are pale shadows of the true contact sports, either direct embedding with the product team or long-term engagement and partnership. In the embedding model, researchers become members of the product team, working side by side on the product in the same environment as the product developers. Because the utility of so many new ideas depend on culture and contextthings rarely written downas well as personal trust and connections, contact engagement is often the most successful approach.
Remember, game plans, no matter how elaborate, rarely work without modification. The players on the field innovate and adapt. Technology transfer is a contact sport. It can be contentious at times, but the rewards for successful transfers are enormous, both in a sense of personal accomplishment and pride and in the long-term success of the companies involved.
MARK GUZDIAL: To get 10,000 high school CS teachers in five years, "we desperately need to involve people who know how to prepare and develop teachersfaculty in schools or colleges of education across the country."
October 13, 2010
In the new National Science Foundation (NSF) "Computing Education in the 21st Century (CE21)" program solicitation, proposers are explicitly asked to "design, develop, and evaluate the impact of pre-service and in-service efforts and strategies that enhance K14 teaching expertise in computing." In Education-speak, "pre-service" means (mostly) undergraduate teacher education programs and "in-service" means professional development for teachers in the classroom. The solicitation points to the "CS 10K" goal: To have 10,000 high school teachers capable of teaching the new Advanced Placement (AP) exam in computer science (CS) by 2015. Today, we have about 2,000 AP CS teachers in the U.S.
How are we going to get to 10,000 high school CS teachers in five years? Here's a quick answer: We're not going to get there alone. We desperately need to involve people who know how to prepare and develop teachersfaculty in schools or colleges of education across the country.
Let's quickly set aside the idea of computer science faculty teaching all those 10,000 future high school teachers ourselves. What do we know about preparing lifelong career teachers? There are employers in IT who argue that we are not particularly good at producing our existing graduates for today's software development careers. High schools are a completely new kind of employer, with new kinds of stakeholders, and new kinds of jobs. Yes, we know computer science. They know the rest. We need a partnership.
How do we convince the schools of education that they want to work with us? That's a harder problem. Budgets are tight. Education schools are not eager to develop new teacher education programs. The just-released "Running on Empty" report shows that few states are teaching anything about computing, so there has to be a parallel effort to create demand for new computer science teachers. From the education schools' perspective, they already teach STEM teachers, and they probably already teach pre-service courses about "technology," although often that means "How to teach a class how to use Excel." Why should they branch out into computer science?
There is a good, mercenary answer: There's money in it. Besides the new NSF CE21 program, the current U.S. administration is funding more efforts in STEM education. The Department of Education and the White House have said clearly that computer science is part of STEM, but little of the STEM education funding is aimed at computer science. That's an opportunity with little competition right now. The time is ripe to form partnerships between CS and education to improve computing education in high schools.
©2011 ACM 0001-0782/11/1000 $10.00
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from firstname.lastname@example.org or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2011 ACM, Inc.
No entries found