|Jack Ganssle's Blog
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 firstname.lastname@example.org. 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 28,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:
- Married To The Team - Working in a team is a lot like marriage.
- Will We Ever Get Quantum Computers - Despite the hype, some feel quantum computing may never be practical.
- Apollo 11, The Movie - A review of a great new movie.
- Goto Considered Necessary - Edsger Dijkstra recants on his seminal paper
- GPS Will Fail - In April GPS will have its own Y2K problem. Unbelievable.
- LIDAR in Cars - Really? - Maybe there are better ideas.
- Why Did You Become an Engineer? - This is the best career ever.
- Software Process Improvement for Firmware - What goes on in an SPI audit?
- 50 Years of Ham Radio - 2019 marks 50 years of ham radio for me.
- Medical Device Lawsuits - They're on the rise, and firmware is part of the problem.
- A retrospective on 2018 - My marketing data for 2018, including web traffic and TEM information.
- Remembering Circuit Theory - Electronics is fun, and reviewing a textbook is pretty interesting.
- R vs D - Too many of us conflate research and development
- Engineer or Scientist? - Which are you? John Q. Public has a hard time telling the difference.
- A New, Low-Tech, Use for Computers - I never would have imagined this use for computers.
- NASA's Lost Software Engineering Lessons - Lessons learned, lessons lost.
- The Cost of Firmware - A Scary Story! - A hallowean story to terrify.
- A Review of First Man, the Movie - The book was great. The movie? Nope.
- A Review of The Overstory - One of the most remarkable novels I've read in a long time.
- What I Learned About Successful Consulting - Lessons learned about successful consulting.
- Low Power Mischief - Ultra-low power systems are trickier to design than most realize.
- Thoughts on Firmware Seminars - Better Firmware Faster resonates with a lot of people.
- On Evil - The Internet has brought the worst out in many.
- My Toothbrush has Modes - What! A lousy toothbrush has a UI?
- Review of SUNBURST and LUMINARY: An Apollo Memoir - A good book about the LM's code.
- Fun With Transmission Lines - Generating a step with no electronics.
- On N-Version Programming - Can we improve reliability through redundancy? Maybe not.
- On USB v. Bench Scopes - USB scopes are nice, but I'll stick with bench models.