Tool_maker, In a perfect world, we would document everything everytime, but it's not always practical. In a large organization, thourough documentation is necessary to handle the logistics of communication. In a small mom-and-pop shop, you can get away with a certain amount of "mental" documentation because direct communication with those who know the details is easier.
This can be taken to extremes on both sides of the continuum. I used to work for a huge multinational conglomerate. We documented ourselves to death, literally. It took seven signatures and half a day to get an ECO approved and documented. That's IF I walked it through myself. The normal lag was about two weeks.
On the other hand, if you lose your human capital who happens to be the sole keeper of odd knowledge for a given project, good luck making heads or tails of it.
You have to find that balance of productivity and proper documentation with which you are comfortable.
This is all over my head so I am way out of my comfort zone here, so if this question does not make sense just consider the source. 99% of what I do is mechanical and when I complete a design and the device is built, it is subjected to a run-off, often with the customer present. If changes are made, the drawings get updated and the alteration is logged. That way if I run into a similar design, I have a record of what did not work and how we corrected it. Is that done in your field as well or would someone else have to go through the whole trouble shooting procedure you just spelled out?
One of my co-workers is so tunnel visioned that he thinks the only important thing is to make the device work. As a result, many alterations may occur with the only record being what he retains between his ears. It drives me crazy, but his family owns the company, so I deal with it.
Good point, Greg. These Sherlock Ohms stories are famous for showing how design engineers have to dispense with all assumptions and dig into areas that could easily get overlooked. If you have any of your own Sherlock stories, please send them along to: firstname.lastname@example.org
Very nice fix; I like your troubleshooting methods and the way you tracked down the glitch. Your example is a valuable lesson for embedded designers who almost always have to figure out concessions with I/O.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.