Best Practices for Hardware Engineers

Thanks Fred, will get that book.

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

joe

me wrote:

News==----

Newsgroups

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

Luhan

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

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

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

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

That's not so bad in hardware design. If I look at a typical ECO, it's not likely (p

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.