For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
By Jack Ganssle
R & D
Research and Development. R&D. It's the lifeblood of tech companies, and it's what we engineers do all day, every day.
I'll present my Better Firmware Faster seminar in Melbourne, Australia February 20. All are invited. More info here.
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?