分享: Engineers do more of D in R&D

htho55

URL source: http://www.eetasia.com/ART_8800504651_480100_NT_b43bfc73.HTM

Engineers do more of D in R&D
6 V, {+ K+ c- U2 F7 q8 p1 O
Posted : 18 Feb 2008

+ U1 ~9 L% ~3 h: _( ^Research and Development. R&D. It's the lifeblood of technology companies, and it's what we engineers do all day, everyday.

; C: d0 R% ?- x* k& gThat's non-sense. There's no such thing as R&D. There's R, and there's D. And the two are completely separate activities.
, t: X; r$ _& u+ J
$ R. v5 w7 V1 L( H5 f% P6 P( \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.
+ G' U$ x- v* t1 E
% L5 S- K2 c. @# P% vResearch 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 we switch to development mode. The result of research is an approach that one can then implement.
! J6 d& p( `3 K/ b
3 o: P- ]$ O# P( {( PBulk of engineering work
. d8 x9 d8 {! d) F6 I) ~+ fDevelopment 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.

7 I/ M) L3 s4 eOne of my top 10 reasons for failed projects is "bad science" or the inability to separate R from D. When one 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 until--with luck--settling on an approach that works.
2 `" r/ g  F$ m/ j
  H. N9 t/ ^+ aResearch simply can't be scheduled. If you don't believe that, please develop a realistic schedule for discovering the cure for cancer.

( M( P" J, ?4 q5 t' z6 h% nYou 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.
: u, I. }/ L( H- B
Yet I constantly see teams conflating R and D, leading inevitably to late or failed projects. Sure, some projects necessarily pursue R and D in parallel. But those can rarely be scheduled with any accuracy.

What do you think? Have you ever had a project disaster because you were doing R the same time as D?
1 G, C( f. J8 Y1 n4 M2 H
, N2 H- ^  }  H4 \8 K8 Z-Jack Ganssle
! p9 K- [1 i8 o" W! oEmbedded.com