Professionals: Development process & best practices ? - Page 1
Forum section: electronics / general

author: Warhawk
author_rank: Frequent Contributor
timestamp: April 18, 2017, 10:47:04 am
content: Hello everyone, I've been thinking about such a thread for a while. I think it could be interesting to discuss development practices with other EEs doing electronics professionally.What kind of tools do you use?How do you track your measurements & lab.notes?What kind of development iterations do you use?What are your best practices you use ?Do you use modern technologies or you rather rely on a pocket calculator plus a pen & paper ?I've been in the industry for 7 years with two different companies and recently realized that I am still quite unorganized. That is strange because I am also a one of those OCD-crazy guysI am constantly struggling with maintaining my oscilloscope measurements results, list of modifications etc. etc.. I usually end up with a printed circuit diagram with a zillion of hand written notes. However, the most of my ideas for future improvement will never make it to any documentation.....Bonus question:I am sure that all of us still like a pen & paper. Do you have a favorite paper notebook, how to you do your notes? Do you record your spontaneous (shower) ideas?@ Dave:Dave, if you read this. Could you consider an episode covering this? What are the things you've seen and like. How to do circuit diagrams and PCBs versioning while remaining sane?RegardsJiri

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 18, 2017, 10:53:50 am
content: There is no such thing as "best practice", only more or less appropriate for a particular situation.

author: tggzzz
author_rank: Super Contributor
timestamp: April 18, 2017, 11:54:25 am
content: Quote from: mikeselectricstuff on April 18, 2017, 10:53:50 amPrecisely.Sometimes it is better to shove rubbish out the door ASAP, and get feedback on it.Other times it is necessary to do extremely heavyweight specification validation (are you building the right thing) and implementation verification (are you building the thing right), with full traceability.

author: capt bullshot
author_rank: Super Contributor
timestamp: April 18, 2017, 12:50:20 pm
content: Tools:Everything that is available and suitable for the problem (according to my skills). Preferably quality tools, cheap things often aren't worth it.Things that I avoid (for the software tools part):- MS Office (Excel breaks your numbers on a regular basis)- "Free" tools that aren't free (e.g. having to register for a free one year period for a SW dev tool)- Tools that bug me with licensing issues: Anything else but "pay once and use forever on any PC you own now or in future" is considered evil- Web / Cloud based toolsNotes:Depends on the project: Ranges from nothing but my to mind to fully blown traceable (using Requirement Engineering Tool). Paper and pencil is often involved for calculations supported by the pocket calulator, simple sketches or just as a temporary notepad.Iterationsif the nature of the project forces us to use it:- (me) Concepts for systems are done by drawing various high level diagrams and then reviewing them according to our process model (short iteration loop here)- (me and others) Specifications will then be derived from the concepts, reviewed and refined (short iteration loop here)- (others) test cases are derived from the specs, reviewed and refined (may reveal weak specifications, short iteration loop here)- (others) Implentation is split to (me) HW and (others) SW departments (may reveal weak specifications, medium iteration loop here)- testing is done by the testers (may result in specifiation changes and medium iteration loop)- system validation (may result in various changes in the system, large iterations is avoided)Otherwise:- (me or other HW dev) Build a hardware (done by some prototyping on perfboard, schematic and layout through CAD department)- (Testers) Test it, find weak spots, modify hardware, if necessary goto previous stepBest practices:Use common sense and club managers to death :-)Technologies:I don't use the latest trendy things like web/cloud based tools. I don't use PC-based instruments (the enormous speed of PC and software evolution renders these devices useless in no time, and having to use the PC as the UI is inefficient). I rely on standalone test equipment, pocket calculators and hardware stuff like paper and pencil. One exception: I prefer to keep track of my schematics using a PC tool (kicad). I use various kinds of simulation and design tools on my PC, depending on the issue. For software development (which isn't a official part of my job) I use the "my favourite editor" and Makefile approach, checking the sources in and out of a versioning system to keep track of the changes.General:I don't keep measurements if it isn't required for the sake of the process or whatever. I don't want to rely on documentation on paper, so about once a month I do clean up my desk and throw away all the paper. Hopefully I've entered all the important stuff into some test report or updated the schematics or whatever. I do clean up my mailbox on a regular schedule, irrevocably deleting everything older than a year. There's nothing important to keep in email, if there was, it would have been saved before.

author: Pitrsek
author_rank: Regular Contributor
timestamp: April 18, 2017, 09:43:16 pm
content: Nice topic!my 2 cents in no particular order. Stuff that works for me:All of the stuff at one place - we call it design report. It contains up to date specification(with changes and reasons for change), rough description of the development - decisions - why I decided to go this way instead of the other, calculations (scanner is your friend), links to external resources, important measurements, links to external files(simulation etc). Once you get into it, the note taking is not that time consuming at all. And it is WELL WORTH IT. few lines and two scope screenshots are usually enough. I also heavily annotate schematics - lot of notes and some links to external files(ie. spice simulation)I tend to split the design into smaller pieces. small piece usually fits nicely on A4 paper. Cleanly defined inputs and outputs, cleanly specified what it should do. And you can very easily define test how you verify that it works (->required test-points).I prototype small parts separately where possible. Just small pcbs - few cm by few cm in size. Same benefits as with schematics + you can get away with 2L board a lot. I keep mounting holes in 1cm grid, and have a base plate with 1cm grid holes. Build and test design piece by piece. If there's a problem, or change of spec of some part of the design, you re-spin just the small board. We have a small CNC for prototyping PCB. worth every penny. From idea to board in a day or two.When all of the pieces are on the grid baseboard, you have a working prototype. Now is time for some more testing, de-rating analysis and worst corner/toleration analysis.... When it's done, I transform small boards schematics into hierarchical schematic of the final multiplayer board. At this point, everything in the schematics has been tested. So it's just implementation.I tend to be test-point heavy, our stuff is not really small, so space is usually not a problem. Helps a lot in testing, saves time(a lot) and nerves as well. When your board is prepared for testing - test points, 0r resistors, spare pull downs/ups etc., it takes 1/3 of the time. And is more enjoyable as wellSimulation is no substitution for bench measurement and bench measurement is no substitution for simulation. You need to make both. Bench measurement is just a snapshot of particular board incarnation. I combine real world measurements and simulations as well. for example: measure component impedance on VNA, I do filter simulation with measured data, prototype filter, measure it and compare it with the simulation.Measure components before use. It's same as tasting ingredients in cooking. Saves lot of troubles.Toleration analysis is great friend, and simulations in general. Test/verify models before use.Check yourself - simulations, calculations - needs to be verified in real world. You design something, you need to test that it holds in real world as well. if not, why?When you are going to measure/test something, what is the expected outcome? have you measured what you expected? no? do you know why?Tie loose ends - something is happening and you don know why? find out what and why, even tough it is not threatening your design directly. If you skip this one, It might bite you in ass big time laterdesign reviews from your colleagues. pair of fresh eyes never hurt.I mix pen and paper with lt spice, qucs, octave and other stuff. Usually start with pen/paper/calc first.Tools - just few highlights from the bench:MX100TP - really nice bench power supplyBODE 100 - LF VNA. 1Hz to 50MHz - I use it for verifying psu stability, measuring filters, input/output impedance, component parameters/impedance profile. Most useful piece of kit on my bench.PCB CNC - not really on my bench, but most useful tool. One of the best investments the company ever made.Good tools don't drive you nuts, good tools helps to get job done. And they are cheaper in the end.Yes, i could remove wire insulation with my nails, but its way faster with Stripax(recommended as well)Works for me. Might add some more next time, it's late in my timezone.Good night

author: CatalinaWOW
author_rank: Super Contributor
timestamp: April 19, 2017, 12:38:05 am
content: Documentation is key to any product that you will see again. You WILL forget important stuff in the months or years since you were last ask to work on a device.The form of the documentation is not as important as doing it. Do it some way that works for you. Which leads to the best practice advice -Budget and plan documentation appropriate to your project at the beginning, and force yourself to spend the budgeted time as you go along.

author: amyk
author_rank: Super Contributor
timestamp: April 19, 2017, 11:55:06 am
content: Quote from: mikeselectricstuff on April 18, 2017, 10:53:50 amI work more on software than hardware and I've been saying the same thing for decades but the software industry is almost religiously observant with their "best practices", it's almost cult-like. I wonder why. EEs seem to be a bit better with that.

author: CatalinaWOW
author_rank: Super Contributor
timestamp: April 19, 2017, 09:17:24 pm
content: Part of the best practices drill is figuring out where you are on the spectrum. If you are in the bottom quintile, best practices can be an effective way to drag you up to average. If you are average you may pick a few cherries here and there. If you are top quintile, best practices are far more likely to harm than to help.A way to make this blatantly obvious is embedded in a quip is used in my arguments with management. It is US based, but you can substitute your preferred professional sport. "If there were a process for winning the Superbowl, everyone could follow it, and everyone would win." It is surprising how many would hear this, point out the obvious logical flaw, and then ask what it had to do with processes, best practices and so on.A serious problem with the advice in the first paragraph is that it is extremely difficult to do this evaluation honestly. Almost every person and organization when asked to rate themselves in any field of endeavor reports that they are "above average".