An engineer is a professional that uses available tools to develop the best possible solution to a problem. A scientist is a professional that explores new possibilities within a given field with the goal of creating new engineering tools.
A few days ago some of the DesignLine websites, including this one, carried an opinion piece by Jack Ganssle with the provocative title "Do engineers really do R&D?" In it Mr. Ganssle defined research an d development and showed that the two are separate functions. He further stated that research has no place in a product development project.
I agree that research is different from development, otherwise why use two names to signify the same thing. And I think the subject needs more inspection than what the short piece gave.
EDA internal research is minimal
I am afraid there is not much research being done by commercial EDA companies. The problem is not a lack of interest, but a lack of funds. The competitive nature of EDA, combined with its relatively slim profit margins, does not generate enough funds for large or long-lasting research projects. What research is done in the field occurs in universities and discoveries in most cases result in new companies being created around one or a few patent claims. Obviously this is an inefficient way of growing an industry, since the results of the research do not contribute in the most efficient way to its growth.
The process of making a success of a startup requires significant investments in building a corporate structure that can successfully transform the result of research into a product, integrate the product into an existing tools flow, market and sell the product, and then maintain it. In the few cases in which a startup is successful in doing all of these things and becomes a candidate for acquisition, the price demanded does not only cover the research and development value, but the value of the entire organization, including not only marketing and sales, but also all other corporate overhead functions like personnel and facilities administration. In almost all cases the acquiring company only needs the product but has to pay for everything else.
Cadence is the EDA company that has succeeded in making it very clear to outside observers that it does have an internal research organization, its Berkeley Labs, and has lately improved the connections between it and the University of California at Berkeley. Yet it continues to be very active in acquiring startups to improve its products portfolio. Is it because the research effort is not big enough, or is it that it is not properly directed toward the correct market segments? Or is it, as Mr. Ganssle suggests, that research is not a deterministic endeavor, and therefore, a company cannot plan a new discovery to coincide with a market need?
Development is often misunderstood
There should not be any confusion as to the purpose of a product development project. Product development should start with a set of well defined requirements that include not only the description of what is to be built, but also the date of product introduction, the cost of the development, and the profits the product is expected to generate. All of these are necessary in order to allow good management of the effort. If any of these are missing, you cannot manage the project, since you will be missing essential measurable characteristics of the effort.
If any research goes on during a product development the fault, almost always, rests in poor product specifications. It is one thing to say that the company should spend resources investigating a particular market opportunity, it is another to define a product based on available scientific results to satisfy a specific market need.
An engineer is a professional that uses available tools to develop the best possible solution to a problem. A scientist is a professional that explores new possibilities within a given field with the goal of creating new engineering tools. The distinction is important and yet not stressed or understood enough. In my opinion the increasingly confused and inefficient way in which we grant patents is contributing to the misunderstanding, and although this is a subject for another piece it needs to be mentioned here.
Finally I need to point out that managers who are good at managing research are almost always not very good at managing development, and the opposite is also true. As Mr. Ganssle points out, in one case the employee is undertaking an activity that has a well specified purpose but no deterministic schedule, while in the other both purpose and schedule are (or should be) well defined. In the case of research the size of the payback cannot be predicted accurately, while in the case of product development the size of the expected payback should be a component of the project's definition.