Do engineers really do R&D?

Embedded Guru - Jack Ganssle has a column on embedded.com called Breakpoints. A highly recommended read if you are or want to be a embedded systems developer. Recently Jack wrote a nice article on what actually R&D is meant for and what actually it is. I would like to post that small article over here or else you can have a look at it @ Breakpoints

"Research and Development. R&D. It's the lifeblood of tech companies, and it's what we engineers do all day, every day.

Nonsense.

There's no such thing as R&D. There's R, and there's D, and the two are completely separate activities.

Research is all about discovering new things. It's the science that ultimately enables the products we build, the metaphorical man-behind-the-curtain pulling the levers to control the machines we create.

Research might also involve discovering new algorithms, like new ways to smooth signals or compress data. "New" might mean new to us but not to the world. So we research an idea or a need, and then switch to development mode. The result of research is an approach that one can then implement.

Development is taking known ideas and using them to build products. That's the bulk of an engineer's work. We transform an algorithm to something physical, like converting a CRC algorithm to C code, to VHDL inside an FPGA, or to logic components.

One of my top ten reasons for failed projects is "bad science," or the inability to separate R from D. When a company starts building a product before really understanding what is being measured the schedule is doomed. Start coding an algorithm without it being sharply defined and, at best, you'll wander aimlessly till, with luck, settling on an approach that works.

Research simply can't be scheduled. If you don't believe that, please develop a (realistic) schedule for discovering the cure for cancer.

You might be able to guesstimate simple research schedules, like doing a search for a known algorithm, but even that is, in my experience, very difficult to estimate. The first "Eureka" is often followed by disappointment when a little experimenting reveals some fatal flaw, requiring more research to find a better approach.

Yet I constantly see teams conflating R and D, leading inevitably to late or failed projects.

Sure, there are some projects that necessarily pursue R and D in parallel. But those care rarely be scheduled with any accuracy.

What do you think? Have you ever had a project disaster because you were doing R and the same time as D?"
-- Jack Ganssle