How to find out what your job is:

• If you’re working on something but you don’t know what it’s good for, you’re doing basic research.
• If you know that but you don’t know if it’ll work, you’re doing applied research.
• If you know it’ll work but not how to build it, you’re doing development.
• If you know  that but you don’t know how much it costs, you’re doing manufacturing engineering.
• If you don’t know if they’ll buy it, you’re in sales.
• And finally, if you don’t know if you made a profit, you’re doing finance.

Does research throw things to development?

Don Monroe, a guy I know and respect, has a narrow idea about the way research connects to development.  He’s correct, but I think he’s not seeing the bigger picture:

The Bell Labs I came to in 1985 was a mammoth enterprise, spanning activities from truly basic research to advanced development, while other parts of the company (then AT&T) made actual products.

Each of these activities was centered in distinct parts of the organization. One of the amusing consequences was the idea that once basic researchers found something useful, they figured they just had to “throw it over the wall.”…

Toward the end of my career, I spent a lot more time with developers, … . It was rather embarrassing to realize that these folks were not hanging out next to the wall, … . In fact, they were far across the field, barely visible, working on the problems that really mattered to manufacturing. Back at the wall lay hundreds of rusting ideas, with no one paying the least attention.

But, who ever thought that science and technology really worked that way? Well, we did, at Bell Labs, but that was just something that we believed because we had to.  We were in a corporation, after all, and we had to justify our salaries.  We believed in that metaphor because the metaphor explained and supported the way our organization functioned.  (It was the usual human backwards justification: do something, then construct a belief that explains why you should do it.)

The reality is that anything that goes “over the wall” needs a lot of engineering, probably at least a decade’s worth, before it becomes technology.  If it ever becomes technology.  Engineers have lots of difficult constraints to worry about, and the reseach guys simply didn’t have time to learn them all.   And, if the research guys did learn all about the engineering difficulties, they’d probably be too discouraged to continue.

So, if you map out a single path to bring a research idea to a product, you are almost bound to be disappointed or discouraged.  There are so many things that could go wrong and so much work to do.

And yet, it is a fact that almost all of our technologies were once basic research.  So, how can that be true if all the research ideas lie rusting on the ground?  That’s because there are many possible paths that an idea can take, so even if the most obvious one is blocked, there are lots of other ways an idea might become useful.  (See, e.g. the discussion of laser and masers, here.)

Many of the ideas that research labs come up with are really solutions waiting for problems.  Initially, they appear useless because they don’t seem to solve anything.  But once someone finds a problem that they can solve, they can be seen to be valuable.  There’s an odd symmetry here: do you discover the problem first or the solution?  Either one can happen, and it’s only the combination that is valuable.

But there’s an odd asymmetry in the way we look at it.  A problem is seen as a challenge, but a spare solution appears to be useless.  However, a better way to look at these spare solutions is that they are intellectual capital.  They are negative problems.  If you have enough solutions hanging around problems just get solved with hardly anyone even noticing that they exist.  That sounds like a better world than the problem-driven world, where one is always desperately seeking solutions.

What’s on the ground on the other side of the wall?

The wall metaphor looks at research in the short term (the shiny ideas rust), and it focusses on just a few engineers (just the ones in Bell Labs in 1985).  Looking at research as a way to get short-term advantage isn’t a good idea.  It’s a long-term process and the benefits often turn up somewhere completely different from where the research was done.

Returning to the very top of the article, the whole point of basic research is that you really do not know what it is going to be good for.  It may not turn out to be useful for those engineers in Bell Labs in 1985.  Instead, it might pay off for some engineers in some other company in some other decade.

So, yes, the ideas went over the wall and the engineers couldn’t use them. But they don’t rust. Ideas are seeds, not screwdrivers. Some of them will germinate, and then 30 years later an engineer will wander by and say “Wow, that’s an odd fruit. I wonder if it’s edible?”

The metaphor should be that basic research is like Johnny Appleseed.  He didn’t make a profit, but he’s remembered for his contributions.