Jack Ganssle, Editor of The Embedded Muse Jack Ganssle's Blog
 RSS Feed This is Jack's outlet for thoughts about designing and programming embedded systems. It's a complement to my bi-weekly newsletter The Embedded Muse. Contact me at jack@ganssle.com. I'm an old-timer engineer who still finds the field endlessly fascinating (bio).

For novel ideas about building embedded systems (both hardware and firmware), join the 40,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.

R vs D

December 12, 2018

In this industry we use the phrase "R&D" will reckless abandon. Managers, especially, seem fond of it. "R&D" has a certain flair, a casual toss-off-the-tongue that suggests one's technical competence.

But there's really no such thing. There's R, and there's D, two totally separate concepts with roots in very different disciplines. R is science: it's the work of extracting new and unknown information from nature, or a system. D is engineering: creating something using the fruits of research. In starting D we've established how things work, and are now harnessing that information in our creative process. As I blogged about here science and engineering are quite different, though complementary domains.

In my seminars, when I discuss scheduling firmware projects it's common for an attendee to ask how one can deal with unknowns, like setting up a peripheral whose characteristics aren't clear. Or, what if the system acquires data requiring some mathematical transformation, one that only experimentation will clarify?

The answer is that you just can't – honestly – schedule these things. It's possible to take a guess, but that guess's error bands might be enormous. I remember using one of the first floppy disk controllers. The datasheet was vague, which should have set off sirens, but as a young engineer I had hubris enough to figure that a few days wrestling with the thing would be all that was required. In fact, eventually I had to fly to the semi vendor's office halfway across the country, work with their FAEs, and finally discover the part had near-fatal and undocumented flaws that required weeks of work to finally tame the thing.

One of my "Top Ten" reasons schedules fall apart is Bad Science. That's when we might think we know how to reduce the sampled data, only to discover that perhaps the signal is 50 dB down in the noise, or that a horrible convolution is needed to establish any sort of correlation to reality. Can you schedule this? No. At least not with any sort of accuracy.

The boss might demand a schedule for the R component of a project. But any sort of a time commitment is a fantasy at best and a lie in practice.

I'm a proponent of being honest and forthright in all human endeavors, in particular scheduling. The IEEE Code of Ethics is a great place to start, which reads in part:  We "promise to be honest and realistic in stating claims or estimates based on available data."

Don't agree? How about this gedankenexperiment: Develop a schedule for the cure for cancer. An accuracy of +/- ten years is acceptable.

Feel free to email me with comments.

Back to Jack's blog index page.

If you'd like to post a comment without logging in, click in the "Name" box under "Or sign up with Disqus" and click on "I'd rather post as a guest."

Recent blog postings: