The joys of having a non technical manager.

[krw]

Then somebody should scream STOP! Making a pcb out of a schematic
that's a mess is just stupidity. The fastest way to get it right is to

I did, right to the VP[*]. There wasn't even an attempt at DRC ("I
pushed the button but nothing happened"), connections left as named
nets (no obvious connections) and no xrefs. The schematic is so bad
I just found two more single pin nets last week. They were only
test points (was going to pull a couple of signals out of the FPGA
for syncing a scope) but there ain't no wires to them. Before it
was released to fab I gave them a 99% chance of first pass failure.
The estimate goes lower every time they ask.

[*] I'm a contractor and my last day is Thursday. I doubt I'll ever
see the hardware (it's supposed to be here Thursday, but that's what
they've been saying for six months).

slow down and clean it up. I sure hope this gang is one of my
competitors.

It isn't. Worse; military.

If engineers designed bridges or airplanes or cars this way, lots of
us would be dead.

Agreed. If you want impressive, try the Shuttle OBS software group.
At least when IBM had it.

 

[Eeyore]

I'm not sure about the 787 line, but in the past, Boeing has kept one or
two (usually the first in a model) aircraft around to do flight testing.

I do much the same too with my own products. Plus you can knock them about and
do extended hi-temp tests on them etc. And use them as loaners.

In some cases, its for test programs unrelated to the product itself.
They have an old 757 they use for testing military avionics and a 767
was used for an IR satellite tracking testbed.

The reality might be that they don't want to turn over the first few
production units to a customer with all the mis-drilled holes and other
flaws that occur early in a production run.

Oh and apparently they have plenty of those. Certain fuselage sections didn't
line up quite like as desired.

At least it's not just Airbus that can eff up with its CAD (the A380 wiring
looms) !

Graham

 

[Frank Buss]

I did, right to the VP[*]. There wasn't even an attempt at DRC ("I
pushed the button but nothing happened"), connections left as named
nets (no obvious connections) and no xrefs. The schematic is so bad
I just found two more single pin nets last week. They were only
test points (was going to pull a couple of signals out of the FPGA
for syncing a scope) but there ain't no wires to them. Before it
was released to fab I gave them a 99% chance of first pass failure.
The estimate goes lower every time they ask.

That's really careless. In Eagle it is called ERC (electrical rule check)
to find errors in schematics (DRC is to find errors in boards, e.g.
crossing tracks with different signales or if they are below the minimum
configured distance apart). A test point with only one wire connected, but
not to something more, is showed as an error in ERC.

Would be interesting to know which program they are using, that "nothing
happened", in order to avoid it, if it is really that bad.

 

[Frank Buss]

Totally agreed on the SMD point. How else can you do it ?

That's easy:

http://www.sparkfun.com/commerce/product_info.php?products_id=495

I have some of these adapters for different packages. It is a good idea to
try to design by reading the datasheet, only, but if you've never used the
chip before, you can get a better feeling for it when testing it on a
breadboard and you can test boundary cases.

Even smaller packages are possible to breadboard, like LPCC with 0.5 mm
pitch, for which I've soldered a breakout board with a stereo microscope:

http://img511.imageshack.us/img511/8824/lpccvl8.jpg

 

[Eeyore]

That's easy:

http://www.sparkfun.com/commerce/product_info.php?products_id=495

Seen that kind of thing before but think of the effect on trace lengths where
high speed is involved.

I have some of these adapters for different packages. It is a good idea to
try to design by reading the datasheet, only, but if you've never used the
chip before, you can get a better feeling for it when testing it on a
breadboard and you can test boundary cases.

I see you've come across some 'dodgy' datasheets too !

Even smaller packages are possible to breadboard, like LPCC with 0.5 mm
pitch, for which I've soldered a breakout board with a stereo microscope:

http://img511.imageshack.us/img511/8824/lpccvl8.jpg

Ouch !

Graham

 

[Scott Seidman]

I agree on going for a smd board directly as current tolerances won't
allow for much else (unlike in the throughhole days). However the
first board just.. might have some misses. Proberbly easy to fix. But
not a working board out of the box.

Good design with test points in the right places go a long way. The test
plan for the circuit should be designed with the circuit.

Designing, receiving, and stuffing a PCB can be much faster than jury-
rigging some hybrid proto-board scheme with SMD adapters, and easier to
debug.

 

[Scott Seidman]

Yes. So don't assume it's an unsellable prototype; make it your best
shot at being the final product. Why not? You've got to attempt a
final product eventually.

Seems semantic to me. If you've got a deployment schedule without design
reviews and testing stages built in, with no facility for patches, you're
just adding these stages in through fudge factors. Then, there's
reliability testing of the finished product. Quality Design programs demand
those to appear.

 

[Scott Seidman]

In general I agree with you -- you should make each board spin your
best shot at being the final/shippable product -- but to play devil's
advocate here:

Yup-- If you don't do this, then your "final production stage" is a
redesign, and needs reevaluation and verification. The best of intentions
lead to an infinite loop!!

 

[Scott Seidman]

- the software guys
can often start doing the bulk of their development on some generic
test/prototyping board with just the CPU, memory, network interface,
etc. on it, while the hardware guys work on The Real Board in
parallel.

I did a lit search one day, and it seems like somewhere around 90% of
medical device problems are software bugs! It's so big a problem that even
extremely simple non-invasive devices with software require levels of FDA
verification that the same device sans software wouldn't require.

 

[Scott Seidman]

Do you ship anything with little blue wires or tack-soldered 0603
resistors (etc.) on the board?

I'm in science. Most of what I do never leaves the proto stage. My little
wires are orange, though. Also, I do correct every PCB in my library, just
in case I need to print another run.

 

[Rich Grise]

Some things you have to get right the first time. Mountain climbing.
Skydiving. Single-hand ocean sailing. Building jet planes.

When I learned to skydive about 20 or so years ago, we were required
to take five static-line jumps before we were allowed to go into free
fall and pull our own ripcord.

Aparently, nowadays, they just do a tandem jump, which I don't really
consider skydiving.

Cheers!
Rich

 

[Rich Grise]

I thought that tombstone engineering was supposed to be dead and buried.

If it crashes precisely on the state line, where do they bury the
survivors? ;-)

Cheers!
Rich

 

[Rich Grise]

In the early days had a couple like that. Ex forces people who never made
the military officer class but on being made industrial managers assumed
they'd get instant respect and attention from the technical oiks. Doesn't
work that way.

I once had a great manager; he really knew his stuff and we all got along
fine - (me, an engineer, and three other techs). One day, he called a
meeting and said that he was giving his notice because somebody else hired
him.

The company hired some complete weenie who didn't know his elbow from
a hole in the ground. I got myself fired by coming in hung-over all the
time; I got another job at another company much closer to home; while
I was working there, I ran into two people (a tech and an engineer) who
were my co-workers under Rick. When the new guy came on, he was such a
lousy manager that they had quit. ;-)

Cheers!
Rich

 

[Rich Grise]

That's easy:

http://www.sparkfun.com/commerce/product_info.php?products_id=495

I have some of these adapters for different packages. It is a good idea to
try to design by reading the datasheet, only, but if you've never used the
chip before, you can get a better feeling for it when testing it on a
breadboard and you can test boundary cases.

Even smaller packages are possible to breadboard, like LPCC with 0.5 mm
pitch, for which I've soldered a breakout board with a stereo microscope:

http://img511.imageshack.us/img511/8824/lpccvl8.jpg

Ick! No offense, but those are some of the worst flying solder joints
I've ever seen!

Cheers!
Rich

 

[Dirk Bruere at NeoPax]

Of course we have to make them work. The difference is that we can
write an ECO to manufacturing to tweak the rev A units, then sell
them. Most of the ECOs are just BOM changes, gain tweaks and such.

A typical gadget will have an FPGA or two (or more) and a
microprocessor. This one

http://www.highlandtechnology.com/DSS/T346DS.html

has about 7K lines of VHDL and 6.6K lines of assembly code. Rev A
works great. We don't usually start on the firmware or VHDL until the
hardware drawings are formally released. And they are not going to
work the first time, although both are usually pretty close. The great
thing about fixing firmware is that it doesn't show... no kluge wires,
no lifted pads, no pcb spins.

It's common to change a few parts values during first-article test,
and to sometimes add a kluge or two. Neither keep us from selling the
rev A pc board.

This discipline saves time and money, and results in better products
shipped.

Ummm... no.
<Manager>
Every software revision and bug is a measure of your total incompetence.
Get it right first time! It's what you're being paid for you moron! Time
is money! etc etc etc
</Manager>

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[Dirk Bruere at NeoPax]

The "get it right the first time" sounds very much like the "zero
defect" programs of the early 1970's. They didn't quite work in the
1970's and are still with us today. The idea is to improve quality by
reducing mistakes. The problem is that the victims of such programs
spend their time minimizing their mistakes, instead of maximizing
their successes. Fear of making a mistake sets in rather quickly,
which seems to be exactly what your new manager is practicing. The
next stage is finger pointing, where nobody wants to accept
responsibility for a mistake. I've attended meetings where the
assignment of the blame took precidence over fixing the problem.

Methinks you might be headed for trouble if this is your new managers
doctrine. I don't have any brilliant suggestions on how to convince
the manager that his approach is wrong. The best I can offer is that
he should consider the possible effects of his policies dragged to its
logical extreme. If every little problem results in excessive
criticism, then people are just not going to report problems. (I've
also seen that happen). The result is that he'll get reports from his
staff indicating that everything is just wonderful, when nothing is
working. It's so much easier to lie and fix the problems quietly,
than to admit that there's a problem, and incurr the wrath of this
manager. Such over-reaction might also cause designers to refuse to
"take ownership" or responsibility for their decisions, resulting the
previously mentioned blame game. If someone coming to this manager
for help with a problem also gets blamed for the problem, then it's
highly likely that nobody will ask for help. This manager is headed
for "isolation".

The managers production background is also interesting. Production
and QA people are usually involved in Zero Defect or Six Sigma
programs in order to improve quality. A questions whether these
programs can effectively be applied to development, where they tend to
stifle creative solutions and promote excessive paperwork.

As for the necessity of doing prototypes, I'm undecided. It's been 20
years since I've done a major project. We tried it both ways, but
never reached a decision. I favored build fast and furious, and found
myself spending my time fixing problems. Others favored a more
careful, step by step, carefully calculated approach, which tended to
extend the project duration, but resulted in much less
troubleshooting. Of course, the longer the duration, the more
oportunity for marketing to change the specifications. With todays
short product cycles, prototyping and even thorough testing of the
final product can becomes luxuries. When there are two or three
generations of new products in development at any given time, nobody
will be interested in fixing the "old" products.

Gotta run.... good luck.

The most productive R&D dept I ever worked in ran as a kind of 'skunk
works'. The owner of the company had R&D as his pet dept. He wanted
something, he came to us and asked for it. We did it - no looking over
the shoulder, no major budget constraints, very little accountancy
paperwork (it all went over his desk). Just Do It ASAP was his philosophy.

Later he got in some 'real managers' and the company went down the tubes
within 2 years.

--
Dirk

http://www.transcendence.me.uk/ - Transcendence UK
http://www.theconsensus.org/ - A UK political party
http://www.onetribe.me.uk/wordpress/?cat=5 - Our podcasts on weird stuff

 

[krw]

I did, right to the VP[*]. There wasn't even an attempt at DRC ("I
pushed the button but nothing happened"), connections left as named
nets (no obvious connections) and no xrefs. The schematic is so bad
I just found two more single pin nets last week. They were only
test points (was going to pull a couple of signals out of the FPGA
for syncing a scope) but there ain't no wires to them. Before it
was released to fab I gave them a 99% chance of first pass failure.
The estimate goes lower every time they ask.

That's really careless. In Eagle it is called ERC (electrical rule check)
to find errors in schematics (DRC is to find errors in boards, e.g.
crossing tracks with different signales or if they are below the minimum
configured distance apart). A test point with only one wire connected, but
not to something more, is showed as an error in ERC.

Semantics. It's all DRC in Cadence stuff.

Would be interesting to know which program they are using, that "nothing
happened", in order to avoid it, if it is really that bad.

Allegro. AFAICT, the models didn't have the information needed.
It's worse.

 

[krw]

Recent case: an Analog Devices dac that occasionally, about 2% of the
time, powers up using the *wrong clock edge* to accept serial data.
Luckily, that was fixable in the FPGA.

FPGAs fix sins that once took yellow wires and board respins.

Reading datasheets very carefully is one of the steps that a
"prototype" mentality tends to skip. There are often gotchas hidden in
the fine print, the foornotes, the application examples, or the eval
board schematic.

A lot of those gotchas are only realized after one has been bitten
("oh, *THAT'S* what that meant).

Should be able to get a spin in a few weeks, though It's been so
long on the current one that I'll likely never see hardware (major
screwups). :-( I leave in a week. ;-)

It's wise to not be associated with disasters.

I'd really like to finish the project (it was already a disaster
before I started, IMO) but landed a real job and they want me there
next week.

 

[krw]

The "get it right the first time" sounds very much like the "zero
defect" programs of the early 1970's. They didn't quite work in the
1970's and are still with us today. The idea is to improve quality by
reducing mistakes.

....and "Six Sigma", "Quality is Free", and any number of other
ridiculous annual programs.

The problem is that the victims of such programs
spend their time minimizing their mistakes, instead of maximizing
their successes.

IME, they sit around inventing metrics they can meet. With an
arbitrarily high denominator the defect "rate" can be arbitrarily
low.

Fear of making a mistake sets in rather quickly,
which seems to be exactly what your new manager is practicing. The
next stage is finger pointing, where nobody wants to accept
responsibility for a mistake. I've attended meetings where the
assignment of the blame took precidence over fixing the problem.

As have I. "Ok, it's *MY* fault. Now that we have that out of the
way, let's fix it."

Methinks you might be headed for trouble if this is your new managers
doctrine. I don't have any brilliant suggestions on how to convince
the manager that his approach is wrong. The best I can offer is that
he should consider the possible effects of his policies dragged to its
logical extreme. If every little problem results in excessive
criticism, then people are just not going to report problems. (I've
also seen that happen). The result is that he'll get reports from his
staff indicating that everything is just wonderful, when nothing is
working. It's so much easier to lie and fix the problems quietly,
than to admit that there's a problem, and incurr the wrath of this
manager. Such over-reaction might also cause designers to refuse to
"take ownership" or responsibility for their decisions, resulting the
previously mentioned blame game. If someone coming to this manager
for help with a problem also gets blamed for the problem, then it's
highly likely that nobody will ask for help. This manager is headed
for "isolation".

Yep, because everyone will walk.

The managers production background is also interesting. Production
and QA people are usually involved in Zero Defect or Six Sigma
programs in order to improve quality. A questions whether these
programs can effectively be applied to development, where they tend to
stifle creative solutions and promote excessive paperwork.

As for the necessity of doing prototypes, I'm undecided. It's been 20
years since I've done a major project. We tried it both ways, but
never reached a decision. I favored build fast and furious, and found
myself spending my time fixing problems. Others favored a more
careful, step by step, carefully calculated approach, which tended to
extend the project duration, but resulted in much less
troubleshooting. Of course, the longer the duration, the more
oportunity for marketing to change the specifications. With todays
short product cycles, prototyping and even thorough testing of the
final product can becomes luxuries. When there are two or three
generations of new products in development at any given time, nobody
will be interested in fixing the "old" products.

No one has the budget to fix old products. If it sorta works...

 

[Joerg]

Yes. So don't assume it's an unsellable prototype; make it your best
shot at being the final product. Why not? You've got to attempt a
final product eventually.

Looks like your company must be a fun place to work at.