In reading back over this thread, I see an important topic evolved from the original - The re-use of code or design versus design-for-the-job approaches.

Admittedly, in this industry we all tend to design mostly the same thing over and over with the same tools, over for different customers. This lends itself to re-use of code and circuitry - not a new concept to any of us.

However, it does have a NEGATIVE aspect. The customer is not getting the best design for his requirements. The customer is not getting the best value for their money.

To quote from my company website's letter from the president (me):

"Too often, small companies are victimized by design subcontractors overlooking their client's best interests in favor of their own. Subcontractors want to reduce their job risk by using familiar circuitry and components whether or not it's the right solution for their client. The problem is conflicting motivations. While the company wants a product they can market successfully, the contractor merely wants to get paid and move on. Without the technical experience to manage the contractor, you often get an overpriced product that is hard to manufacture and doesn't work the way you envisioned. Managers get fired over these frustrating results... We solve the conflicting motivations dilemma by...(I won't share our solutions)"

In this I play upon the fears of the endless supply of managers that have been burned in the past by design contractors that sold them a "re-heated" design. I see it all the time... companies come to me with endless stories of designs they got burned on.

To be fair, its not just the designers fault. The company hiring them lacked the expertise to curb the shortcut available to the designer. If they had hired better project managers - they would not have the problems. But companies are not the brightest form of organized effort... :)

So, I cannot really recommend everyone re-heat their designs. You can make money, but its like writing in C... it will get the job done, but it won't be the best possible implementation.

-aka j