Dave's Rules to Live By
OK, some are more of a guideline than a rule 


Introduction

Here are my rules for life, engineering and the universe. Enjoy.

Dave's Rules

Murphy's law of Information

If information exists in two places then at least one of them is wrong.

Corollary to this rule:
Cut and paste is the devil! The easiest way to create a new document is to copy an old one and the make a few changes to it. But when you do this you are duplicating a bunch of information and making it hard to find out what most people really need: the differences between the two documents (or products).  I regularly curse tech writers for this. Also now any updates need to be duplicated in multiple documents. Breaks Murphy's law of Information.

Murphy's Law of Probability

If the probability of something going wrong is 50-50 then it will go wrong 90% of the time.
Scientists hate this one.

Rule of Temperature drift

Everything drifts with temperature.
Corollary: Anything can be used as a thermometer.

Rule of Oxidation

Everything oxidizes.
Well just about everything. Gold, nickel, teflon are pretty good though. Sunlight (UV) is the devil.
Chemicals are the other devil.

Murphy's law of analog

Every amplifier will oscillate, every oscillator will amplify.

Analog Design Rules:

Always use series damping resistors (10-50 ohms) on Power-FET gates. Fast drivers,  driving the large gate and D-G capacitances will ring or oscillate.
When driving capacitive loads fast, the inductance is a killer.  Found this out the hard way in 1978 by failing EMI testing.


When you get crazy (unexpected) DC values, turn on the 'scope.
It's probably oscillating.


Unless you have a damn good reason, use a single ground plane. But still keep digital signals on one side and the analog on the other away from analog ones.

It's Always the Ground(s)

In troubleshooting, it's (almost) always the ground.
Bizzare and un-explainable stuff, check for loose or crappy grounding.
Digital noise getting into analog: poor ground plane splits.
Ground bounce in digital systems: B happens when unrelated A occurs.
Most EMI issues? bad grounds or shields, or gaps in the chassis grounds. Copper tape, EMI gaskets, better shielding. all grounding issues.
Audio crosstalk? More grounds.
RF systems? Ground everywhere, bu twatch the trace impedance.

Arduinos kill me. One or 2 ground pins for 20 switching and 10bit analog signals. Should be about 1:1, 4:1 max, not 10:1. You'd never get away with this crap on a high speed TTL or CMOS system. MORE GROUNDS IS ALWAYS BETTER. Sorry to yell.

*** Boating ***

Beginning of New England boating season:

Get the boat completely ready before launch.
NE summer is way too short and is for sailing, not boat work. Fix everything important. You've got all winter and most of the spring and fall  to do it.

End of New England boating season:

In New England, haul the boat by Columbus day.
Late October is nor'easter season. IE. The Perfect Storm, Larry's boat....

Never sail on a schedule.

Sailing on a schedule will cause you pain. Wait until good weather. Your boat and crew will appreciate it.
Corollary to this:
When meeting someone via a sailboat, they can specify where or when, never both.

*** Guns ***

Having a gun in your house increases the probability of someone who lives with you dying by gun about 5x. 30,000 gun deaths a year in the US. A mass shooting just about every day. Don't get one. But we don't need stricter gun laws. Sure.

*** Driving ***

Gil's Motorcycle rule:

"Everyone I know who rode a motorcycle got mangled. Don't ever get a motorcycle, kid". OK, dad.

Dave's Driving rule:

30-40,000 people die every year in car accidents in the US. Every time you get in a car, remember that you could kill someone or be killed.

*** Engineering ***

Rule of engineering time estimates: from Mike Burka
http://www.projectteamblog.com/index.php/improve-task-estimates-multiply-by-pi/
Always multiply project task time estimates (particularly from an engineer) by pi.

Good, Fast, Cheap. Pick 2.

No production process shall include Blood or a PhD.

At Infraredx the product detects lipid plaque in human coronary arteries using NIR spectroscopy. The hard part was doing this through flowing blood. So in the early days, every system was tested with real human blood. Then a PhD would analyze the data to determine pass or fail. When I found this out, I created this rule. It took several years of effort to create a product test that did not require blood or a PhD in final production test.

When your production final test yields suck, you have inadequate unit testing.

And probably have a design fault.

The cost of a problem (and it's rework cost)  increases 10x for every product step: CAD design, prototype,  board build, system build, final test, customer use.

A component selection, value or design change might take an engineer several minutes to fix before the first prototypes are built. Then every step costa about 10X in time and $$$. By the time a problem hits the customer it can take weeks to resolve and fix. Not to mention the bad will.

The corollary: Find every fault at the earliest possible point.

Datacube vs Zoll: Datacube: $10-15M in sales, with 2-3 full time test engineers. in 2005 Zoll had $200M sales and 0 test engineers, terrible final test yield, and HASS testing on 100% of units: Giant N2 tank to stress-test every unit: Cold, hot and vibration. "We test the quality in" Gag!!

A corrolary is that when a production manager suspects a design fault, he is probably correct. Be humble as you investigate the problem. At first the problems really are design or testing faults. After a few are shown to be Manufacturing faults, the Manufacturing Manager will begin to trust engineering. For a while.

Law of manufacturing problems:

It's almost always engineering's fault.
Generally true. Either the design is marginal or the process is not error-proof.


Story about Analogic CD. The Analogic T&M department was about to ship its first product with a CD. I asked the VP of manufacturing what level of process documentation was needed to instruct the production person how to burn and label a CD. He said "Just some general notes about the specific file, label, etc. I then asked the production supervisor the same question:  He said to make a detailed procedure with screen shots of every step. We did the general thing, no screen shots. When the first CDs were shipped, the customer called to report a problem. The CD labels were applied to BOTH SIDES OF THE CD! Apparently the person programming and labeling the CDs had never used a CD before! The supervisor was 100% right.

Other Design Rules

Never develop your own Bus, Serial interface, Processor, Language, or Operating System. Of course I have done or managed every of these, but I try really hard not to break this rule.

Dave's law of calibration:

"You lie and I'll swear to it."

Jeffs law of Dirt:

Dirt cannot be created nor destroyed, just moved from one place to another.

Risk of pre-announcing your product.

Don't pre-announce your product. Remember Adam Osborn. Osborn pre-announced their new PC, and sales for the older model dropped to 0 while customers waited for the new one. The company died as a result.

When I was at HP Medical, Marketing released new brochures for a beautiful new medical monitor. Connected to it was the new pressure transducers that were not yet in production. The result was that customers immediately stopped buying the older transducers. Sales dropped to 0 while they waited for the new (and unavailable yet) transducers. 

You can't fix (or control) what you don't measure.

Applies to everything, control systems, money, education, sociology, politics... 

Bernie Gordon: Nyquist applied to Project Management

Bernie Gordon had many rules. One of my faves was that he applied Nyquist sampling theorem to project management:
Sample a project (at least) twice as often as it can screw up.
If a project can go off the rails in a week, sample it (review the status, Discuss it with engineers, implement any changes) twice a week.

Shoot the engineer and ship the product

If you don't, the engineer will work on it forever. "Just one more improvement / feature / bug fix...."




  Dave's Home Page

Last Updated: 6/4/2021