Looking for Best Practices for Design Engineers

in the private sector it varies, generally with the size of corporation. High turnover large corporations have well documented design practices and well documented list of documents that must be produced as part of the project. Smaller corporations tend to have very little formal documentation (unless its required as part of the contract). Generally the smarter engineers know exactly what they need to document to be successful and the dumber engineers don't, and forcing the dumber engineers to document their work just results in a pile of worthless incomprehensible documentation.

best

or

recent

should

Tell

sure

Thanks for the reference. I'll try it.

When I started engineering, everything went into an engineering notebook. Some of my old ones are scrapbook collections of meeting notes, lab setups, Polaroid scope pictures, business cards, fortune cookie papers, etc. I also developed a three-ring binder habit - all papers I got related to a project were punched, sorted, and bound. Some big projects expanded into multiple volumes - hardware design, firmware design and listings, part-list histories, component data sheets, etc.

A few years back I started keeping a daily log on my desktop pc - just a few notes that describe what happened that day, with contact names, email addresses, web links, phone numbers, etc included. I make a new file (a Word document) every month - the current one is log0506.doc. It's much easier to search than a notebook. I still use the notebook for lab sessions and the like that may need dated, witnessed data plus the three-ring binders (4 so far on the current project which started in January and should have ended by now). I have a separate project folder on my pc, with subfolders for hardware, software, meetings, etc. One folder holds copies of pdf datasheets for the parts in the design, and I no longer have the need for 4

6-foot bookshelves full of databooks.

For firmware design/documentation, I start with a written specification (in MIL-490 standard outline). If you can't write a spec, you don't know what you're going to do, so don't start. Usually the first design step is a set of Visio flowcharts, showing a simple overview of the code functions, and then detailed charts of any state machines (circles labeled with state names and arrows labeled with state-transition criteria). I code directly from the state machine diagram into a switch/case structure in most cases, with give and take between the two until they match up.

A

I have never really tried it, I still use real paper, but you can actually make drawings and write text, on a graphic tablet like :

A german collegue also used a whiteboard on which he wrote with a special pen and when he pressed a button, the content was saved in a file or sent by email. This was used during videoconference sessions and that looked very high tech;)

Hi Anton,

This unfortunately does not address the proprietary database issues. Remember the Domesday project. Do you happen to have a BBC Microcomputer with an LD player attached? :)

I used to be a big fan of doing everything electronically, but it's proven to be much more trouble than it's worth.

I still do archive my invoices, tax returns, credit card statements etc. electronically - but then I only expect to need them for at most seven years.

For general work, I have a series of logbooks describing what I'm working on. More like a diary than anything else; these are scratchpad books where anything and everything can be sketched and annotated. The books are not project-specific.

Once I work something "final" out from my scratchings in the logbook, I transcribe the "finished" circuit, calculation, or whatever, into the appropriate project file. Of course, it might get some polishing once inserted into the real product.

The customer gets a copy of the project file on CD-R as part of the deliverables.

Just use your editor. I use my Favorite Text Editor (edwin editor: ee) for as long as I can remember for project logs. As a bonus it is easy to paste in data from program files, but I find myself mostly using different sessions for programming and logging.

This is a sample from today and yesterday:

--------------------------

2005 jun 22 wed

• make a 4.2 directory.

• test all.

• add a solution for namescooked and constant stuff.

• add make clean to Makefile, that really removes all generated files

make cleanall now really deletes everything. Remains

- use that to automatically clean 4.1 old ci86 and 4.0 directories

• make sure namescooked works okay

- delete assembler files from 4.2 aka cvs root

- delete dieren files from 4.2 aka cvs root

- delete superfluous files from cvs root

- use that to further clean 4.1 old ci86 and 4.0 directories

- script that moves non-doubles to a single directory.

- move loose items into library file

2005 jun 23 thu There is a difference now between the archive of e.g. as6809s.frt in ciasdis and cvs, caused only by the introroduction of version 5.1 what a pity! First: get a good split w.r.t. assembler.

• delete assembler files from 4.2 aka cvs root " CVS: Removed Files: CVS: testset8080 testset8086 transforms wc CVS: ass.frt ps.frt testas386a testset386 testset386a testset6809 CVS: as6809.frt as80.frt asalpha.frt asi86.frt asm386endtest CVS: ----------------------------------------------------------------------

Files related to the PostIt FixUp assembler are now sourced at ciasdis. What is left here is a symbolic reference to the ciasdis files. README.assembler reflects this. At last wc is renamed to mywc. "

In Makefile.add is a list of files that have to be cleaned with ``make cleanall' but currently aren't.

-------------

Invaluable 10 weeks down the road.

--

--
Albert van der Horst,Oranjestr 8,3511 RA UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@spenarnc.xs4all.nl http://home.hccnet.nl/a.w.m.van.der.horst

This is fine for keeping track of software status, but for schematics etc. A way to handle sketches and other material is desirable. I currently keep PDF versions of schematics and PCB overlays, and scan read-line drawings to pdf to keep in electronic format.

Regards Anton Erasmus

Honestly, I don't see how that can be applied to a real situation.

I think that if the boss dosen't have some basic clues about how to do his job then he should be sacked anyway. In my experience there are only two ways to get ahead 1) Suck up to the boss at every oppurtunity. Maybe if you can become his right-hand-man, then you can have some input as you wrote. 2) Reveal his failings to management so that he may be sacked.

If one has a truly ignorant or stupid boss it is better to keep such information to yourself. Alternatively it may be useful to reveal it when the QA audit comes around.

Johnny.

alternatively:

2) Reveal his failings to management so that you will be sacked.

You guys must work for some pretty horrible companies.

JM

Average only. They are thick up there, don't mess with them;)