Best Practices for Hardware Engineers

[[email protected]]

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.

Here is my list in no particular order

1. Always have a top block diagram, in your schematics and in your FPGA
code
2. Follow the System Engineering Design Process Model
3. Document, Document, Document your work
4. Modularize your work
5. Try a Top Down design approach instead of Bottom Up
6. Ask for Peer Reviews and code walk throughs
7. If a standard exits then follow it.
8. Manage time, don't let time manage you.

The list serves two purposes for me. First I believe it will permit one
to handle a complex task and increase the success of the task. Second,
I would like to get my co-workers to follow some sort of common design
process. I work for the government in a small Research and Development
branch of 30 people. A few people practice some of the items on the
list, but many don't. I don't have any experience in private industry
and I would want to know if design teams in private industry follow a
set of best practices or design processes? When a new person joins the
team does he/she get introduced on how the design teams develop
projects? I'm just trying to determine what's it like in a private
company, are there a set of rules one must follow? I'm always trying
to think of practices that can help me manage complex tasks and hope to
hear from others how they do it.

Thanks,
joe

 

[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.

Here is my list in no particular order

1. Always have a top block diagram, in your schematics and in your FPGA
code

Yes, sheet 1 of each schematic (fpga's are schematics, too!) but it's
usually created last, just before the drawing is archived.

2. Follow the System Engineering Design Process Model

What's that?

3. Document, Document, Document your work

Yes, yes, yes. On the schematics and source code, not to the side.

4. Modularize your work

Meaningless, or maybe dangerous.

5. Try a Top Down design approach instead of Bottom Up

Definitely dangerous.

6. Ask for Peer Reviews and code walk throughs

Sure, but it's mostly casual, walkaround stuff, not scheduled
meetings.

7. If a standard exits then follow it.

Or break it, whichever works best.

8. Manage time, don't let time manage you.

Oh, please.

The list serves two purposes for me. First I believe it will permit one
to handle a complex task and increase the success of the task. Second,
I would like to get my co-workers to follow some sort of common design
process.

I think a good design process consists of hundreds of good habits, not
just a short list of rules. It evolves over years and is hard to write
down.

John

 

[Luhan]

Here is my list in no particular order

1. Always have a top block diagram, in your schematics and in your FPGA
code
2. Follow the System Engineering Design Process Model
3. Document, Document, Document your work
4. Modularize your work
5. Try a Top Down design approach instead of Bottom Up
6. Ask for Peer Reviews and code walk throughs
7. If a standard exits then follow it.
8. Manage time, don't let time manage you.

I don't get much out of your list, here is mine...

1. Make sure your client knows what he's getting into - time, money,
problems, etc.
2. Dont use any parts that the sales reps say are replacing the current
ones.
3. Document only as much as you need for yourself, offer extensive
documentationt to the client after the project is done. Let them pay
for as much as they want.
4. Check out the convetional solutions, use only as they apply.
5. Dont take on any project unless you have it mostly designed already.

All projects consist of parts, these parts fall into the following
catagories:

I. Stuff that you have done before.
II. Stuff that you have not done but others have.
III. Stuff that nobody has done before.
IV. Stuff that is commonly regarded as not possible.
V. Stuff that violates laws of physics.

Do the project starting with the worst rated parts, that way you can
fail early and save your client time and money!

Luhan

 

[Jim Thompson]

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.

Here is my list in no particular order
[snip]
7. If a standard exits then follow it.

I like that one ;-)

[snip]

...Jim Thompson

 

[John Larkin]

I don't get much out of your list, here is mine...

1. Make sure your client knows what he's getting into - time, money,
problems, etc.
2. Dont use any parts that the sales reps say are replacing the current
ones.
3. Document only as much as you need for yourself, offer extensive
documentationt to the client after the project is done. Let them pay
for as much as they want.
4. Check out the convetional solutions, use only as they apply.
5. Dont take on any project unless you have it mostly designed already.

6. Write the manual first.

John

 

[Wayne Lundberg]

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.

Here is my list in no particular order

1. Always have a top block diagram, in your schematics and in your FPGA
code
2. Follow the System Engineering Design Process Model
3. Document, Document, Document your work
4. Modularize your work
5. Try a Top Down design approach instead of Bottom Up
6. Ask for Peer Reviews and code walk throughs
7. If a standard exits then follow it.
8. Manage time, don't let time manage you.

The list serves two purposes for me. First I believe it will permit one
to handle a complex task and increase the success of the task. Second,
I would like to get my co-workers to follow some sort of common design
process. I work for the government in a small Research and Development
branch of 30 people. A few people practice some of the items on the
list, but many don't. I don't have any experience in private industry
and I would want to know if design teams in private industry follow a
set of best practices or design processes? When a new person joins the
team does he/she get introduced on how the design teams develop
projects? I'm just trying to determine what's it like in a private
company, are there a set of rules one must follow? I'm always trying
to think of practices that can help me manage complex tasks and hope to
hear from others how they do it.

Thanks,
joe

I always start by imagining the final bill of materials, then put item by
item into a spreadsheet, then add detail as each component is visualized,
designed and detailed including make/buy decisions, manufacturing processes
and estimated costs. When the final design is sent to the shop/vendors the
documentation is a done deal. Communication to all team-members is easy as
expanding the spreadsheet to a Gantt chart for weekly reviews or the like.

Wayne

 

[Luhan]

6. Write the manual first.

Hey, thats a good one. I wrestled back and forth with one client for
weeks as they gave me vague and conflicting functions for the product.
Maybe, let *them* write the manual first!

Luhan

 

[Ancient_Hacker]

I've usually (almost always) found that a top-down design ends up being
useless.

It will have all kinds of pretty layers and boxes and lines and
interfaces.

But quite often:

(1) You don't know ahead of time how many layers are adequate.
(2) You end up with a design that's "logically" correct, but may be
several powers of ten too slow.
(3) You have to break up the design anyway in order to delegate
ther parts to people that can implement them.
(4) The final design doesnt mesh at all well with the available IC's
or modules.
(5) the cost of the interfaces, wires, cables, connectors will exceed
the cost
of everything else.

Your mileage may vary.

 

[Nico Coesel]

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.

Here is my list in no particular order

1. Always have a top block diagram, in your schematics and in your FPGA
code
2. Follow the System Engineering Design Process Model
3. Document, Document, Document your work
4. Modularize your work
5. Try a Top Down design approach instead of Bottom Up
6. Ask for Peer Reviews and code walk throughs
7. If a standard exits then follow it.
8. Manage time, don't let time manage you.

I'm missing an important one:
Test whether each module you make works as expected with any input
combination. Design modules to deal with faulty input properly

 

[Luhan]

I've usually (almost always) found that a top-down design ends up being
useless.

It will have all kinds of pretty layers and boxes and lines and
interfaces.

But quite often:

(1) You don't know ahead of time how many layers are adequate.
(2) You end up with a design that's "logically" correct, but may be
several powers of ten too slow.
(3) You have to break up the design anyway in order to delegate
ther parts to people that can implement them.
(4) The final design doesnt mesh at all well with the available IC's
or modules.
(5) the cost of the interfaces, wires, cables, connectors will exceed
the cost
of everything else.

Your mileage may vary.

Conceptualize top down.
Develop bottom up.

Its like a skyscraper, you gotta build it from the bottom.

Luhan

 

[Winfield Hill]

Jim Thompson wrote...

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.

Here is my list in no particular order
[snip]
7. If a standard exits then follow it.

I like that one ;-)

If it exists, then follow the exits, yes.

 

[EE123]

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.

Here is my list in no particular order

1. Always have a top block diagram, in your schematics and in your FPGA
code
2. Follow the System Engineering Design Process Model
3. Document, Document, Document your work
4. Modularize your work
5. Try a Top Down design approach instead of Bottom Up
6. Ask for Peer Reviews and code walk throughs
7. If a standard exits then follow it.
8. Manage time, don't let time manage you.

The list serves two purposes for me. First I believe it will permit one
to handle a complex task and increase the success of the task. Second,
I would like to get my co-workers to follow some sort of common design
process. I work for the government in a small Research and Development
branch of 30 people. A few people practice some of the items on the
list, but many don't. I don't have any experience in private industry
and I would want to know if design teams in private industry follow a
set of best practices or design processes? When a new person joins the
team does he/she get introduced on how the design teams develop
projects? I'm just trying to determine what's it like in a private
company, are there a set of rules one must follow? I'm always trying
to think of practices that can help me manage complex tasks and hope to
hear from others how they do it.

Thanks,
joe

I'll include the first couple of lines from
"Calender for a RUSH JOB!"


Day: Gen Fri Fri Thu Wed Tue Mon
8 7 6 5 4 3 2
16 15 14 13 12 11 9


Notes:
1) Everybody wants his order delivered yesterday. With this
calender, you
can order on the 7th and have delivery on the 3rd.
2) All customers want their orders on Friday, so there are 2
Fridays
every week.
3) There are no unproductive Saturdays, Sundays or holidays.

etc


Dave

 

[Adrian Tuddenham]

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.

Here is my list in no particular order

1. Always have a top block diagram, in your schematics and in your FPGA
code
2. Follow the System Engineering Design Process Model
3. Document, Document, Document your work
4. Modularize your work
5. Try a Top Down design approach instead of Bottom Up
6. Ask for Peer Reviews and code walk throughs
7. If a standard exits then follow it.
8. Manage time, don't let time manage you.

If it is for academic research, allow an order of magnitude tolerance on
every specified parameter (if any).

 

[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

 

[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

 

[Luhan]

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

Hey, don't hold back, tell us what you *really* think!

Luhan

 

[Richard Henry]

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.

Is that a rule?

 

[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.

Is that a rule?

The only rules you can count on are conservation of energy and
conservation of charge, and I'm not sure about that last one.

John

 

[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

Hey, don't hold back, tell us what you *really* think!

Luhan

Aside from my grumpiness, I really think all good engineering boils down to
one single point of note ... it's the old Scottish adage, "Look after the
pennies and the pounds will look after themselves"
john

 

[Wayne Lundberg]

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.

Is that a rule?

If you look at almost any innovation you will see the new idea or method
came from outside the normal established procedures. Look at the transistor.
It took years for vacuum tube engineers to realize the true potential of the
transistor. Sony is the one to recognize it and licensed it and look what
happened.

The best example ever of this paradigm paralysis is to be found in Geneva,
Switzerland in the late 60's when the research team presented the idea of
quartz to the factory owners and big wigs in the time-keeping industry.
These managers/owners were so in love with their gears and jewel bearings
that they did not even patent the idea their own researchers had come up
with. Texas Instruments and Casio saw the idea at a technical conference and
the rest is history.

So yes... a lot of great engineering comes from braking the rules.