When I was at MIT (decades ago) we had to build a lot of stuff ourselves, not just design it. in mechanical engineering we had to make stuff we'd designed as well (this was pre-CNC) explicitly in part so we would learn what it was like to be on the receiving end of a stupid part and to learn that those guys in the blue overalls who didn't have the fancy education were at least as smart as us and knew a hell of a lot more about mfg than we ever would.
Nowadays you should still be building a lot of stuff, on your free time if nowhere else. But the manufacturing has become so complex and specialized (SMT, 3D printing, etc) that you have to spend time with folks who live and breathe that stuff.
If, like me, you aren't working for Apple/Cisco/Toshiba/Siemens then that means hiring a consultant :-(
There are so many walls. One, how does the end user use your product? Do the sales/marketing whoever is generating specs. know anything about the engineering side? If the product is for a specific customer, has anyone in engineering talked to people expected to use it, not just to their management?
And then there is the internal stuff. Do the hardware guys talk to the software guys, or the production people or the maintenance guys?
Because all of these are required to make a successwful product. The brief time I was at Telxon, they were started to implement a system where they would survey their customer's needs, develope to 90% of those needs and the product design committee consisted of members from hardware, software, production and maintenance with all having to sign off on everything before development would start. And then there wer gates established so that a project could be evaluated and had to get a green light before proceeding. But then, they were swallowed by the Evil Empire and...
Something to point out here is that in software, particularly in web applications, Agile development, often in the form of some sort of scrum, is a software only analog of what Mr. Bigg developed for Telxon. Agile makes a huge difference, just look at healthcare.gov or even worse, Oregon's implementation of it. Both shows why approaches like the waterfall model aren't great ideas...
Every engineer's education should have to include dismantling and fixing a product that was designed without consideration for maintainability. One with sharp edges opposite corroded bolts behind tangles of indistinguishable wires.
I expect most people could nominate at least one classic combination of those features. As a boy, I learnt a great deal about the idea from taking apart my mother's Austin 7, (which had broken its crankshaft). By today's standards, that was probably quite a benign specimen.
@perl_geek: "Every engineer's education should have to include dismantling and fixing a product that was designed without consideration for maintainability. One with sharp edges opposite corroded bolts behind tangles of indistinguishable wires."
Brilliant. Have you seen the repairability ratings that iFixit gives devices after the team tearsdown a device?
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.