Best Practices for Hardware Engineers

[Fred Bloggs]

Fred,

Thanks for responding to my post. So far it looks like it has angered
many and was not my intention. My intention was to "learn" from others
concerning their successes. Let's say a new engineer showed at your
work. I'm sure you are a very knowledgeable and successful engineer.
What advice would you pass on to him/her concerning success? How do you
measure success? If its not a list of items or habits, then what is
your response? Not to be mean, but do you practice what you preach and
go around your workplace and tell others, "your not fit for the job"?
Or, you pass on some words of wisdom? Anyways, thanks for your
suggestions, it is a good topic, Best Practices, and I'm finding a lot
of important views on engineering.

Thanks Fred,
joe

I don't know what is your problem that you think this subject matter is
undocumented or nonexistent in the literature. A good introduction with
tons of further reading references would be Electronic Instrument
Design, Architecting for the Life Cycle, by Kim R. Fowler, Oxford U
Press, 1996. This text exhaustively covers every aspect of the kinds of
things you're interested in.

 

[[email protected]]

I don't know what is your problem that you think this subject matter is
undocumented or nonexistent in the literature. A good introduction with
tons of further reading references would be Electronic Instrument
Design, Architecting for the Life Cycle, by Kim R. Fowler, Oxford U
Press, 1996. This text exhaustively covers every aspect of the kinds of
things you're interested in.

Thanks Fred, will get that book.

 

[[email protected]]

You are absolutely right. Let me say thanks for everyone's input and
ask that we end this topic.

joe

 

[Luhan]

You are absolutely right. Let me say thanks for everyone's input and
ask that we end this topic.

You can start a topic, but you can't end it. I do congradulate you for
lighting the fire on this one.

Luhan

 

[John Larkin]

On Wed, 31 May 2006 21:46:22 +0100, "John Jardine."



Hello, I have a list of Best Practices for Hardware Engineers that I
would like anyone to look over and tell me what you think or what
should be added to the list.
[...]
joe


This same question, in the last couple of years has turned up twice.
It reeks of residence within some management diploma course module.
Specifically, that module that that dreams it can teach up and coming,
thrusting, young pointy haired managers, how to enforce structure and
organisation onto those bolshie, engineering slob types.
john


An 8-item list of how to do engineering would be like an 8-item list
that tells you how to replace a kidney or how to land a 747.

Besides, good engineering usually involves breaking rules.

John

John,

Hello, thanks for responding to my list. You are right, an 8-item list
is too small. Could you add some items from your experiences that
enabled you to produce a successful product. What are some rules that
you've broken to achieve success?

Thanks, and keep the comments coming.
joe

HEHEH! Hey , John- write more!- You know how most of us just like to sit
around and mental midget over amorphous, unstructured, undefined,
philosophical crap- I believe these sessions are called "meetings"-
better you than me

I average a couple of meetings a day, if you define a meeting as a
gathering of 3 or more people. They're usually unplanned, unscheduled,
short, and productive. People can't work together if they don't talk.

But today, I have two nasty, formal, planned ones: the annual
shareholders' meeting (where they always reelect me to the Board)
followed by the Board meeting, where they always reelect me Chairman.

Woo-hoo.

John

 

[Luhan]

Absolutely not! They're hiring you because you know how to make things
work, and they don't (that's why you had so much trouble getting good
specs). _YOU_ write the manual first, so you can show them how the
thing will work when you're finished. Then if they don't like what
you've given them, you write another version -- that you know you can
make work -- so they can verify it's what they need and buy off on it.
This process of give-and-take makes good specs out of mush.

Then nobody has excuses, and almost all customers will be happy.

Absolutely Wrong! I was once hired to engineer an 'Air Guitar'. There
was no way for me to know what the hell they wanted from this device.
Having them write the manual would have forced them to be specific on
what the unit was to do and exactly in what manner.

My job is to give the client something he will be happy with in the
end. This is not always exactly what he asks for at the start. One
thing that he may consider a minor feature could double the engineering
time. Conversly, I may advise him on a nifty feature he did not
specify that would add almost nothing to the cost of development.

I fight my battles on the front end; my clients tend to be very happy
with the end result.

Luhan

 

[John Larkin]

Hello, I have a list of Best Practices for Hardware Engineers that I
would like anyone to look over and tell me what you think or what
should be added to the list.
[...]
joe

This same question, in the last couple of years has turned up twice.
It reeks of residence within some management diploma course module.
Specifically, that module that that dreams it can teach up and coming,
thrusting, young pointy haired managers, how to enforce structure and
organisation onto those bolshie, engineering slob types.
john

An 8-item list of how to do engineering would be like an 8-item list
that tells you how to replace a kidney or how to land a 747.

Besides, good engineering usually involves breaking rules.

John

John,

Hello, thanks for responding to my list. You are right, an 8-item list
is too small. Could you add some items from your experiences that
enabled you to produce a successful product. What are some rules that
you've broken to achieve success?

Thanks, and keep the comments coming.
joe

You seem to think that electronics design is a rule-driven,
quantitative, intellectual activity, when in fact is a rule-breaking,
qualitative, emotional activity.

It's like tennis: you don't learn it from books, you learn it on the
court.

John

 

[Rene Tschaggelar]

Fred,

Thanks for responding to my post. So far it looks like it has angered
many and was not my intention. My intention was to "learn" from others
concerning their successes. Let's say a new engineer showed at your
work. I'm sure you are a very knowledgeable and successful engineer.
What advice would you pass on to him/her concerning success? How do you
measure success?

Success is when the stuff works. Failure is when it doesn't work.
Oh you want a grade in it ? Well, the quicker it works the better.
Another grade ? The cheaper the better.

Rene

 

[John Larkin]

Conservation of misery, also. Like when the only possible solution
to a problem introduces another problem, just as nasty.

That's not so bad in hardware design. If I look at a typical ECO, it's
not likely (p<0.2) to be followed by a secondary corrective ECO.

Software is different. The more complex the system, the more likely
that any change will break something and need another change. One
explanation for the increasing delay between Windows versions is that
Windows is approaching the p=1.0 point, where any change, including a
fix, is likely to break something else.

John

 

[mc]

Software is different. The more complex the system, the more likely

that any change will break something and need another change. One
explanation for the increasing delay between Windows versions is that
Windows is approaching the p=1.0 point, where any change, including a
fix, is likely to break something else.

What I think has happened with Windows is that the API is very complex, and
programmers find out how it works by experiment, and write programs that are
dependent on bugs or undocumented behavior, which of course will change in
later versions. So every improvement breaks some application software.