In every company where I worked, there was another very common complaint. Management would ask the engineers to put together a very aggressive development schedule all the engineers would endorse as being realistic, then management would publish to the world, a more aggressive schedule without adding resources to engineering. It made for long hours, bad attitudes from Engineering towards Engineering executives and company officers, and generally increased the stress and mistakes as the engineers began cutting corners in development. So, if you take all the other complaints listed in the research, you will see all of them magnified when this very common problem is added to the mix. I would say this is the number one issue that if resolved would make Engineers so much more happy to come to work. Can I get an AMEN?!
Doug: I agree with everything you're saying ONLY when the supervisors do not have the time or knowledge to get deeply involved. Just calling and saying a project is very important and we need to step it up is not enough. They need to dig down to the nuts and bolts. They need to be able to explain back to you in at least a layman's level of what is going on, what the risks are in terms of time and budget, and what choices you're making to deal with them.
I don't mind them working off an unrealistic Ghantt chart from paradise if they understand that several things will slip and can understand why. I agree completely that it's demoralizing to work off an aggressive schedule and then get the vacuous feedback "Why's it slipping a few days? This project has high-profile visibility." The engineering thinks sarcastically, "Oh, Well if it is has 'visibility' then drat, I should actually be trying to do a good job. If no one were looking, I'd just be slacking off."
My comments on the TFI study:
- Importance of EoL data cannot be overemphasized. Usually reps, disties, and mfrs say the part is either EoL or in no danger of being discontinued any time soon. (The article said some engineers talk about EoL in terms of MTBF. In my world EoL only means discontinuation of the part. I wonder if there was confusion on the part of the interviewers OR if the term has different meanings in other areas of engineering.)
- Need for a single place to compares components across mfrs - This would be nice. Digikey does a decent job of this, but they don't have that many parameters. Sometimes the parameters they have only allow me to narrow it down to a thousand parts, which is worthless. At that point I head to the mfrs websites. They sometimes have better parametric searches, and they have only one mfr's parts to wade through.
- Use of forums and social media - I use a lot of Google with boolean search operators to filter down to just what I'm looking for. I only use a forum if it's dedicated to my particular area. For example, I use TI's E2E forum because it has TI experts answering questions and knowledgeable users who are using that part. If I went to a general website, it's unlikely I'd find someone using the specific part I'm asking about.
- Websites that charge - If engineers knew the site was good, they would be willing to pay. The trouble is a big companies sometimes the purchase requisition process is so onerous that the web site would do better asking the engineers to pay with their own money.
- On every "pain-point" I thought to myself, "What we do now is much easier than looking through stacks of databooks." I started practicing engineering in the mid 90s just as everything went up on the web.
A comment on electronic component sales in general:
Many engineers are introverted and find it tiresome to interact with people. But computers are not up to the level of taking the place of a good rep. The best way to get engineers to design in parts IMHO is to have a kick-ass parametric search system, good app notes, and then have good reps (the same person every time, if possible) available by chat or someother online medium.
The article's conclusion:
It says engineer's would benefit from having all the info in one place but are deeply distrustful of single-source anything. This is so true.
After reading the study and the accumulated responses, I find myself a little confused about how I should respond to some of the current pain points.
Most of the time, budget, requirement changes and unrealistic scheduling is and always have been part of the business. Reguardless of cause, they are inherent in just about every business cycle. In some cases, the business competition drives the issues. In others, it is the marketing perceptions. In some others, it is a life saving threat issue.
After 40+ years of being in and or observing the electronics industry I really do not see any "reasonable" solution to those issues. Either real or imaginary, they become the drivers.
The other issues about information on parts and design aides just make me really jealous. Think about trying to find components using data books that are several "years" old. Having to telephone suppliers who might take "days" to return your call. Doing all of your calculations on a slide rule. Circuit diagrams were hand drawn. No simulations. Test equipment totalled an oscilloscope and a multimeter. Now add a one of a kind development scenario where the "protoype" was the final product. Each project is unique, so no reuse capability exists.
That was my environment for a lot of years. I understand that the complexity of electronics has increased a good deal over the decades, but your support capability today was unthinkable when I started. I do not blame you for complaining, nor do I think your "pains" are invalid. What most people are really complaining about is that they are rushed too much to do the best engineering job they could, and that problem has not changed.
But doing the impossible has always been the challenge for engineers. It was how we earned our merit badges. To say the you worked on project X and got it to work was like saying you had won the lottery. Others treated you with envy and awe because of all of the "stories" they had heard about the project.
When I went into management, I knew the real issues, but what I looked for was how the engineers responded.
A good engineer gets the job done with what is available in the time that they have. Its an assinine way to do product development, but it is the world we live in. Still, it separates the engineers from the wanna be's.
Yes, having all of the information you need available at all times would be nice. Unfortunately, it will never be the case. The information and technology just changes too quickly and mistakes will always exist that will cause you significant set backs and headaches.
So while I feel your pain, I also understand that the only way you can truly deal with them is to keep yourself prepared as best you can and do what you can with what you have. I never finished a project without saying that I now know how I "should" have done it. I think most of you would agree. But it is the experience we gain on each project that enables use to do better on the next project. It is your reputation for getting things to work that get you selected for the most challenging projects. If you wait until you have everything you need, you will never get the project done.
Learn to adapt, compromise and use "good enough" as you must. Write down your lessons learned and make suggestions to improve the process. If you get lucky, some things will change. Just don't be disappointed if they do not.
Thanks for reading my rambling. If you always do your best, you can never fail yourself.
All four of the pain points are valid, but I'm not sure I agree about the order, and there is something to be said for the type of pain also. Productive and unproductive pain in projects is typical. In my experience, productive pain is the "agony of creation" - that it nearly always takes something out of you to create something new, and engineer it to work the way you want.
The early stages of bringing big system blocks together in a functional layout, and then drilling down to hardware/software level is pure productive pain. Yes it hurts, but you know you're getting somewhere. Time is burned very quickly during these stages, especially if you're designing at the bleeding edge. This can involve many intense supplier meetings, looking at roadmaps and introduction dates, also factoring in the risk when time slips and screws up the whole design.
Even dubugging hardware and software is productive pain. Obviously accepting that this is a necessary part of production, and that good design methodologies minimise the effect of errors in design, debugging is still positive pain.
The unproductive pain is anything that falls into the class of "could have done better". Incomplete documentation, the process of keeping vendors and suppliers aligned whilst you are caught in the middle keeping your design on time and on budget, specifications which change and so on. With suppliers of very variable quality, this is still a problem, dependent on who you are dealing with.
I'd say the most painful and largely unproductive area is that surrounding the management of customers and suppliers. A very time consuming and frustrating experience can easily be had if either doesn't have their act together in either their requirements in terms of a customer, or documentation and support in terms of a supplier.
I was surprised to see the pricing was high up on the list of mentions by engineers as one of the most painful points in development. I'm wondering whether this is because pricing is not really seen as the design engineers domain, or if it is just one of those very frustrating things that gets in the way of the real development. Either way, this falls into the class again, managing suppliers and customers.
I thought the report did a good job of sizing up the challenges and making it clear that engineers all have similar problems when it comes to finding reliable, timely information. However I found that it didn't bring up what I perceive to be the root cause of the problems engineers face when designing the newest generation of products
I have found that the design cycles across multiple companies stack up on top of each other. For example, I have been on many design projects that work on "preliminary datasheets' that miss key information, and then build my prototypes with 'beta Si.' This is clearly a response to trying to get product to market as fast as possible. It makes more sense from the perspective of efficient work flow to wait for the completed chips needed for the system and then begin the product design. But planning for a serial process like that is like trying to design a control system to not have any overshoot -- it takes much longer to get to the final point of pre-production. I think going for the 'critically damped' system of accepting some information to come late is a reasonable trade-off, but I am not envious of the managers that have to make schedules to account for the randomness this causes.
Hearing someone say, "We can't design the _____ system yet because we need a 'TBD' parameter from the chip manufacturer" always makes me worry since it will only be addressed when other systems have been set in stone and cannot be adjusted, making integration that much more difficult. But like true problem solvers, we face the challenges at hand and complete them the best we can.
When I think about it, I am actually impressed with how well engineers work on this 'parallel design path'. Designing a product which uses key components that are developed by another company is no small task and we seem to do OK at it, even if scheduling gets messy.
What was not asked definitively in the report was the level of complexity of the projects each surveyed engineer was working on. This dictates how info is handled. Complex projects require extensive research and planning. Simple ones, not as much.
Complex projects are usually beyond the scope of all content from communities, datasheets, app notes, and other resources.
Simple projects have often been done before, and well. In this case, it is just a matter of time before one find the examples or resources. In some cases, the "older" engineer has already designed/or know where to reference a design to get the job done.
As time goes on, I think the use of the internet/social media will prevail as the number one way work gets done. In fact, I would not be surprised if crowd-sourcing is used to build projects. Which I could see as an elimination of the workforce. Paying crowd-source people would be far less than a full time engineer making $80-100k.
I agree with Cabe on crowd-sourcing. Inniocentive (www.innocentive.com) has been doing a great job with this. They have not been doing a lot of electronic related projects but I'm sure that will change.
There is a 'hidden gem' to accelerate design time, Digikey has a reference design library: http://designs.digikey.com/library/index
You can actually sort by a designs performance in the larger categories. It's almost like cheating.
I wonder what resouces will be available for our kids when they are our age?
What resources will be available for our children? That is assuming they will even be designing. As manufacturing leaves most countries for cheaper areas, so does design work.
Go back 40 years in the USA. Most design and manufacturing was done inside the country. Today's figures, near zero manufacturing and a sharp reduction in the number of design jobs.
The biggest "pain point" for the next generation will be finding an actual job.
If not this, then it will be funding for the next big idea. When a foreign country does not abide by patent rules and copies a design and has the manufacturing power of China, what will anyone do?
The same forces that make it easy for things to be manufactured and designed abroad make it easy for all of work to be done anywhere. They make it no longer necessary for manufacturing to be physically close to where the design work is done.
I do think traditional jobs are decreasing, but that's not the same as work decreasing. The idea of a "permanent" job where you hire someone and take care of him for life does not work anymore.
I am not knowlegeable about the details of patent violations across borders, but this is the thorniest issue that's coming out of how easy it is to send information and objects around the world. It comes up if one country wants to make a law to protect the environment or labor and companies in another country view it as a backdoor way for the other country to prop up its domestic industry unfairly. Barriers to trade will keep decreasing, and these thorny issues will be with us for decades as we work them out.
A new element14 sponsored study entitled "Design with Efficiency: Toward a Streamlined Process for Electronics-Industry Design Engineers"
listed the following “pain points” for design engineers as they embark on new projects or incorporate new technologies into their designs:
1. Initial design stages (before prototype assembly and testing) typically require
the most time and effort to gather all the necessary information.
2. There’s never enough time to properly utilize every relevant source.
3. Incomplete information is common across relevant sources.
4. Managing customer and vendor relations throughout the design process can be
complicated, consuming even more time and resources.
Do you agree or disagree with the items on this list, and, if you agree, would you change the order of the “pain” elements listed?
Finally, are there “pain” elements missing (such as continuously changing design parameters, etc.)
Read the study and let us know what you think