Best Practices for a Hardware/Embedded Designer

Hello, I'm looking for some information that describes some of the best
practices or habits for successful electronic design or embedded
design. I'm trying to convince some co-workers that it is important to
document their work and follow standards in their designs. Some of my
co-workers are very fast designers and are respected by their peers,
but in their rush to get the design done they often ignore standards
and don't document their work, such as in their schematics or in their
FPGA code. I feel these habits and behavior actually wastes money, by
that I mean that if someone has to take their undocumented work, they
won't know what is going on. I realize that I might not be able to
change more senior engineers, but I might be able to leave an
impression on the newer engineers. If anyone knows of some habits or a
list of some best practices that make a successful design, please pass
them onto me. Most of these habits I would assume fall into proper
system engineering.

thanks,
joe

jjlindula@hotmail.com wrote:
> I realize that I might not be able to
> change more senior engineers, 

With the habits you describe, they shouldn't be senior 
engineers.  If they won't aquire the discipline you need, 
replace them.


Bob
-- 

"Things should be described as simply as possible, but no 
simpler."

                                              A. Einstein

<jjlindula@hotmail.com> wrote in message 
news:1118527532.481778.251660@g47g2000cwa.googlegroups.com...
> Hello, I'm looking for some information that describes 
> some of the best
> practices or habits for successful electronic design or 
> embedded
> design. I'm trying to convince some co-workers that it is 
> important to
> document their work and follow standards in their designs. 
> Some of my
> co-workers are very fast designers and are respected by 
> their peers,
> but in their rush to get the design done they often ignore 
> standards
> and don't document their work, such as in their schematics 
> or in their
> FPGA code. I feel these habits and behavior actually 
> wastes money, by
> that I mean that if someone has to take their undocumented 
> work, they
> won't know what is going on. I realize that I might not be 
> able to
> change more senior engineers, but I might be able to leave 
> an
> impression on the newer engineers. If anyone knows of some 
> habits or a
> list of some best practices that make a successful design, 
> please pass
> them onto me. Most of these habits I would assume fall 
> into proper
> system engineering.
>

The software development industry realized more than four 
decades ago that it had a similar problem.  Beginning in the 
early 70s, some of the intellectual powerhouses of the 
computer world began studying and writing about the problem. 
Some names that you should check out are Ed Yourdon, Edgar 
Dijkstra and Gerald Weinberg.  Topics include "structured 
walkthroughs", "egoless programming" and "code reviews".

These are tools for managing all kinds of software 
development efforts, but, with minor changes in terminology, 
they can be adapted to many kinds of technical development 
efforts.  It's all about management.

Successful implementation of most of these methods will 
bring some changes to the work environment.  One major 
change is that it is going to "front load" your projects 
with design, which will dramatically re-arrange the 
timelines in your project plans.  Another major change is 
that individual ownership of pieces of the project changes 
to group ownership of the project.  These are fundamental 
changes that require the total commitment and support of 
your management from the top down.  You probably cannot 
ignite a "grassroots" effort to make the necessary changes.

For an organization to get as badly fouled up as the one you 
describe, there must be a long history of neglectful, 
ineffective, divisive management.  You are likely to find 
that most of the resistance to change comes not from your 
technical peers, who tend to want to do things right anyway, 
but from the numbskulls who have a vested interest in 
preserving the status quo.  Look-up "management by crisis" 
for more information.

If all else fails, fear of hunger can be a great 
motivational tool.

Good luck.

Hi Joe,

Carnegie-Melon's Software Engineering Institute has a process called
CMMI - Capability Maturity Model Integration - which aims to remove
many of the problems you're seeing, and not just in SW shops.

Taken from

http://www.sei.cmu.edu/cmmi/general/


"The CMMI models improve upon the best practices of previous models in
many important ways. CMMI best practices enable organizations to do the
following:

    * more explicitly link management and engineering activities to
business objectives
    * expand the scope of and visibility into the product life cycle
and engineering activities to ensure that the product or service meets
customer expectations
    * incorporate lessons learned from additional areas of best
practice (e.g., measurement, risk management, and supplier management)
    * implement more robust high-maturity practices
    * address additional organizational functions critical to its
products and services
    * more fully comply with relevant ISO standards"

Be warned: this stuff is pretty radical in places operating as you've
described.

Ciao,

Peter K.

Bob Cain wrote:
> 
> 
> jjlindula@hotmail.com wrote:
> 
>> I realize that I might not be able to
>> change more senior engineers, 
> 
> 
> With the habits you describe, they shouldn't be senior engineers.  If 
> they won't aquire the discipline you need, replace them.
> 
> 
> Bob

Hard to do, if you don't own the place.

I have seen good software engineering evolve out of this sort of chaos, 
only to fall back into rubble through actively bad management.  You can 
only hold it up when your entire group is committed (and not under 
threat of termination for trying to front-load the project).

-- 
-------------------------------------------
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

jjlindula@hotmail.com wrote:
> Hello, I'm looking for some information that describes some of the best
> practices or habits for successful electronic design or embedded
> design. I'm trying to convince some co-workers that it is important to
> document their work and follow standards in their designs. Some of my
> co-workers are very fast designers and are respected by their peers,
> but in their rush to get the design done they often ignore standards
> and don't document their work, such as in their schematics or in their
> FPGA code. I feel these habits and behavior actually wastes money, by
> that I mean that if someone has to take their undocumented work, they
> won't know what is going on. I realize that I might not be able to
> change more senior engineers, but I might be able to leave an
> impression on the newer engineers. If anyone knows of some habits or a
> list of some best practices that make a successful design, please pass
> them onto me. Most of these habits I would assume fall into proper
> system engineering.
> 
> thanks,
> joe

If you own the place, start looking for replacements. If you don't, 
polish your resume. Resend your sad story to news:comp.arch.embedded.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Hello all, I want to thank you for your comments. I should have said
that in 90% of the work that is done is my shop will always come back
to the shop for upgrades, or will be passed onto another engineers for
testing. In most cases the original engineer is around to answer any
questions, but in a hypothetical case if that design engineer left the
job position and he/she did not document their work (either in their
code or schematics) or decided not to follow a communication interface
standard then the new engineer must take additional time to figure that
out. I work for the government and when I see this happen I get upset
because this extra time costs the taxpayers money. Furthermore, I have
taken a few Systems Engineering courses and what I most remember is to
document your work and that most engineering problems occur at the
interface. I get frustrated when I see my co-worker not following these
suggestions and don't set a good example to the newer engineers. Seems
to be if one follows some of the things in a Systems Engineering
course, or a Risk Management course, or an Interoperability course you
actually save the tax payers money for the total cost of the design.

Thanks again and if you find any good web resources on best practiced
please let me know.

joe
jjlindula@hotmail.com

On 11 Jun 2005 15:05:32 -0700, jjlindula@hotmail.com wrote in
comp.dsp:

> Hello, I'm looking for some information that describes some of the best
> practices or habits for successful electronic design or embedded
> design. I'm trying to convince some co-workers that it is important to
> document their work and follow standards in their designs. Some of my
> co-workers are very fast designers and are respected by their peers,
> but in their rush to get the design done they often ignore standards
> and don't document their work, such as in their schematics or in their
> FPGA code. I feel these habits and behavior actually wastes money, by
> that I mean that if someone has to take their undocumented work, they
> won't know what is going on. I realize that I might not be able to
> change more senior engineers, but I might be able to leave an
> impression on the newer engineers. If anyone knows of some habits or a
> list of some best practices that make a successful design, please pass
> them onto me. Most of these habits I would assume fall into proper
> system engineering.
> 
> thanks,
> joe

First, if you are going to post the same thing to multiple groups, you
should cross-post it, that is put the names of all the groups involved
in the 'newsgroups' line of ONE message posted to all the groups.
Posting the identical message to multiple groups separately is a waste
of storage space and bandwidth and considered less than good manners.

Secondly, there is actually nothing special about embedded engineering
in this respect at all.  The best group for discussing this is
news:comp.software-eng.  Check their back traffic on Google and look
up their FAQ.

-- 
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

I have a hunch that your engineers aren't documenting anything they are
doing for a simple reason. You need them if you want to make any changes
and so they can never be fired.

I am not sure if you can legally even call them Engineers because for them
to gradudate from any respectable engineering program they need to learn
and adhere to IEEE or other established documentation standards.

If you suspect that the first case is true, there is a simple way to get
them to fix their ways. Tell them that they have to document their work,
and possibly register them in a course that teaches that. If they still
don't want to do that, bring in a few guys and have them hang out around
the office pretending to go through their design and trying to understand
it...once they realize that they are about to be replaced and no lack of
documenation will help them they'll clean up pretty quick.


		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com

correlious wrote:

> I have a hunch that your engineers aren't documenting anything they are
> doing for a simple reason. You need them if you want to make any changes
> and so they can never be fired.
> 
I doubt that it's that intentional.  Most often when I see this kind of 
behavior folks believe that they are getting their work done quickly and 
efficiently, without letting the documentation get in the way.  This is 
a difficult thing to deal with in a good designer at the best of times, 
but if the environment is such that they're getting rewarded by 
management for getting their work done quickly and efficently then it's 
darn near impossible.

> I am not sure if you can legally even call them Engineers because for them
> to gradudate from any respectable engineering program they need to learn
> and adhere to IEEE or other established documentation standards.

In reverse order:

2:  Where did you graduate from?  I went to two different schools for my 
BSEE and MSEE; there was some attention paid to penmanship in 
hand-written materials in my 1st- and 2nd- year classes, but beyond that 
there wasn't any formal attention paid to documentation (and thank you 
Prof. Riley, for constantly reiterating "if you write it, sign it and 
date it").  Before I entered the real world learned far more about 
proper documentation in chem and physics labs than I ever did in 
engineering courses.

1:  Less than half of the folks working in "engineering" departments in 
high-tech manufacturing meet the legal qualifications of "engineers", at 
least as "engineer" is defined in Oregon.  This is mostly because such 
places have no legal requirement to have licensed engineers on staff, 
and getting the license is a pain.
> 
> If you suspect that the first case is true, there is a simple way to get
> them to fix their ways. Tell them that they have to document their work,
> and possibly register them in a course that teaches that. If they still
> don't want to do that, bring in a few guys and have them hang out around
> the office pretending to go through their design and trying to understand
> it...once they realize that they are about to be replaced and no lack of
> documenation will help them they'll clean up pretty quick.

Having management and the engineering leads all singing from the same 
sheet of music works well without any classes -- and I suspect that no 
amount of classes would help without a daily infusion of process from 
the above two groups.  An electrical lead that I know would have all his 
people start every design review with a slide that showed a schematic of 
the process, with the particular step they were in highlighted. 
Thinking back, I wish I had done that and the next big project I'm on I 
think I will.

-- 
-------------------------------------------
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com