Communications - March 2011

exception handling when they are actually working in JavaScript.

Maybe we should be teaching scientists and engineers about computer science more generally. But as Greg Wilson points out, they don’t want much—they see computer science as a “tax.” What’s the core of computer science that even scientists and engineers ought to know? Alan Kay recently suggested a “Triple Whammy” (http://computinged.wordpress. com/2010/05/24/the-core-of-computer- science-alan-kays-triple-whammy/) defining the core of computer science:

1. Matter can be made to remember, discriminate, decide, and do.

2. Matter can remember descriptions and interpret and act on them.

3. Matter can hold and interpret and act on descriptions that describe anything that matter can do.

That’s a pretty powerful set. It goes way beyond Python vs. Java, or using Perl to check genome sequences with regular expressions vs. using MATLAB for analyzing data from ecological simulations. How do we frame the Triple Whammy in a way that fledgling scientists and engineers would find valuable and learnable?

Reader’s comment

The worrying trend I see is that many computer engineering graduates are interested in learning only a large set of programming languages, but dislike courses like algorithm design, not realizing that these languages are merely tools for implementing solutions. The end result is what you could call technicians but not engineers.

—Farhan Ahmad

Greg Linden “Research in the Wild: Making Research Work in industry” http://cacm.acm.org/ blogs/blog-cacm/97467

How to do research in academia is well established. You get grants to fund your group, attract students, publish papers, and pump out Ph.Ds. Depending on who you ask and how cynical they have become, the goals are some combination of impacting the field, educating students, and personal aggrandizement.

Research in industry is less established. How to organize is not clear.

The purpose is not even well understood. The business strategy behind forming a research group sometimes seems to be little more than a variant of the Underpants Gnomes’ plan in South Park. Phase 1: Hire Ph.Ds. Phase 2: Phase 3: Profit!

Generally, researchers in industry are supposed to yield some combination of long-term innovation, improving the sophistication of technology and products beyond simple and obvious solutions, and helping to attract talented and enthusiastic developers.

To take one example in search, without researchers who know the latest work, it would be hard for a company to build the thousands of classifiers that ferret out subtleties of query intent, document meaning, and spamminess, all of which is needed for a high-quality search experience. Information retrieval is a field that benefits from a long history of past work, and researchers often are the ones that know the history and how to stand on giants’ shoulders.

Even so, there are many in industry that consider researchers an expensive luxury that their company can ill afford. Part of this comes from the historically common organizational structure of having a separate and independent research lab, which sometimes looks to be a gilded ivory tower to those who feel they are locked outside.

The separate research lab is the traditional structure, but a problematic one, not only for the perception of the group by the rest of the company, but also because the researchers can be so far removed from the company’s products as to have little ability to make an impact. Many companies appear to be trying other ways of organizing researchers into the company.

For example, Google is well known
for integrating many of its researchers
into product groups and shifting them
among product groups, working side-
by-side with different development
teams. While on a particular project,
a researcher might focus on the part
of the problem that requires esoteric
knowledge of particular algorithms,
but they are exposed to and work on
many problems in the product. When
this group comes together, everyone
shares knowledge, and then people
move to another group, sharing their
knowledge again. Moreover, these
ephemeral teams get people to know
people, yielding valuable peer net-
works. When a tough research prob-
lem later comes up and no one nearby
knows how to solve it, finding the per-
son in the company who can solve it
becomes much easier.

Reader’s comment

Research as a process and a profession and as a mind set is quite different than product-making. Pushing the two too close together or expecting people to be good at both may not always be optimal. See my “Research as product” post on the FXPAL Blog.