System Engineering in the R/D World

In R&D, there is no such thing as "policy" or "corporal memory". I have never met a "scientist" or "researcher" who did acknowledge that skill and competence were personal attributes, that each person have to make an effort to gain for themselves or communicate to others. "What do you mean I can do better? I am a professor at [insert your favourite university or R&D organization here], for crying out loud!"

Not necessarily. Some attention to reproduceable results would keep certain not entirely all that good techniques from enetering the scene. Remember, R&D is all about "publish or perish." Making a second check of those "brilliant" results might lose a much cited paper.

"Never measure twice."

The common R&D argument is that "we do this only once, there is no need

to build a system around this activity."

Again, since an R&D activity usually is done only once, or a couple of times at most, no one see the need for systematic planning.

These are the factors that in my experience separate R/D from engineering. In R&D, stuff like the above are generally considered "waste of time and talent".

Heh, that's my average experience when I try to make some algorithm or technique work, be it from an academic paper or an in-house technical report: The documentation doesn't work. Either there are typos, the key

tricks are left out or "documentation" is taken to mean "a short general description of a concept". I don't think I have ever implemented a technique based on a single document "and the references therein".

I always had to go to other literature, and more often than not, do the

complete derivations myself to make sure I got it right.

Rune

Is this the one that couldn't divide very well. I.e., had the floating point bug?

Clay

.....

Go ride a bike. Turn a corner.

Now start thinking about/analysing what you are doing. Turn a corner.

DNA

Thanks a million for the reference link, I'll check it out.

Yes, But certainly not the one who made P4's slower than P3's, for numerical operations.

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
|  Analog/Mixed-Signal ASIC's and Discrete Systems  |    manus    |
|  Phoenix, Arizona            Voice:(480)460-2350  |             |
|  E-mail Address at Website     Fax:(480)460-2142  |  Brass Rat  |
|       http://www.analog-innovations.com           |    1962     |
             
I love to cook with wine.      Sometimes I even put it in the food.

ROTFLMAO ;-)

...Jim Thompson

-- | James E.Thompson, P.E. | mens | | Analog Innovations, Inc. | et | | Analog/Mixed-Signal ASIC's and Discrete Systems | manus | | Phoenix, Arizona Voice:(480)460-2350 | | | E-mail Address at Website Fax:(480)460-2142 | Brass Rat | |

| 1962 | I love to cook with wine. Sometimes I even put it in the food.

Isn't that clock for clock? My understanding was that they had to make architectural changes in order to be able to run the things at a higher frequency..

JEremy

Depends how much time, money, and resources you've got and what you are working on. On military projects for example (I've worked on several) you've usually got plenty of all three. In this case you would (and are required to) do a lot more paperwork stuff like requirements analysis, risk management, supportability, integration planning etc. But to real design engineers this sort of stuff adds no real value, i.e. you aren't using your time to produce anything useful.

A commercial project on the other hand with limited budget, time and resources, where you are expected to produce miracles, you just need to get the job done. Any formal process that doesn't add value in getting the job done is simply ignored. Of course you always keep one eye on the important side stuff like requirements, testing, maintainability etc, but you couldn't care less about formal risk management and integration planing for example.

Peer reviews are valuable in ANY situation. Often these are informal like "I'll check the schematic over while I'm on the can".

Dave :)

Rune,

It's clear that you're heavy on the "R" in R&D. I'm heavy on the "D" in R&D in these descriptions but I've also done "R" and there are different objectives to be sure. Reproducibility is important in "R" and early stages of "D". Producibility is important in "D". Reproducibility should be a foregone conclusion at this stage.

et cetera

Fred

You mean the ones with de devision bug inside?

*SCNR*

bye Thomas

You mean the ones with de division bug inside?

*SCNR*

bye Thomas

HI,

SE (System Engineering as well as Software Engineering) is always a problematic field. I don't think, that you will find a project that uses all possibilities nor a (sucessfully finished) project that ignores every aspect of SE.

I think the most companies use a more or less golden middleway.

We use any point mentioned above but in some cases a bit weaker than my old SE teacher would like. We did this whole effort only for ASICs in the past but actually changed to use these techniques in every design. Of course this leads to a overhead of paperwork especially for small projects but pays when it comes to products (not very funny if a bug rise after the last chance of repair is gone and therefore need a rebuild).

bye Thomas

And the F00F bug

-- "Electricity is of two kinds, positive and negative. The difference is, I presume, that one comes a little more expensive, but is more durable; the other is a cheaper thing, but the moths get into it." (Stephen Leacock)

Good way to get killed.

John

The centipede was happy (quite!) Until the toad for spite Asked, "Pray; which leg comes after which?"

That threw his soul in such a pitch He lay distracted in a ditch, Considering how to run.

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Praise the messenger!

Make sure the rest of the group hears the praise, not just his manager.

Many years (10?) ago, my boss handed me a paper titled "Bugs are Good" by Doug Clark. Scribbled on it was "must read". I haven't been able to find it online, but it's easy to find references to it. (We were all working for DEC/Digital at the time.)

The main theme, at least as I remember it, is that you should praise the people who find bugs. It take a group-culture approach to understand the logic. Finding bugs today is better than having them find you tomorrow.

The other half is that you want other people to check your work. They have a different point of view. They won't make the same errors/blunders that you made. (hopefully)

-- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Reprise:

The centipede was happy (quite!) until the toad in fun Asked, "Pray; which leg comes after which?" That threw his soul in such a pitch He lay distracted in a ditch, Considering how to run.

Jerry

--
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Either that, or Intel employed more of the cheap workforce, relied heavily on automated tools and procedures and used less of the expensive brains.

Adrian

Is that Kipling or other? Just 'know' I've seen it before.