Best Practices for Hardware Engineers

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.

Reply to
Fred Bloggs
Loading thread data ...

Thanks Fred, will get that book.

Reply to
jjlindula

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

joe

me wrote:

News==----

Newsgroups

Reply to
jjlindula

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

Luhan

Reply to
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

Reply to
John Larkin

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

Reply to
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

Reply to
John Larkin

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

Reply to
Rene Tschaggelar

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

Reply to
John Larkin

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.

Reply to
mc

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.