Breaking News
Blog

The Wall Between Design & Reality

View Comments: Oldest First | Newest First | Threaded View
dvhw
User Rank
Rookie
You have to spend time on the other side of the wall
dvhw   3/24/2014 12:02:24 PM
NO RATINGS
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 :-(

jkocurek
User Rank
Rookie
Re: You have to spend time on the other side of the wall
jkocurek   3/24/2014 2:20:28 PM
NO RATINGS
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...

perl_geek
User Rank
Freelancer
Maintainability
perl_geek   3/24/2014 6:46:15 PM
NO RATINGS
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.

Susan Rambo
User Rank
Blogger
Re: Maintainability
Susan Rambo   3/25/2014 7:23:04 AM
NO RATINGS
@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?


August Cartoon Caption Winner!
August Cartoon Caption Winner!
"All the King's horses and all the KIng's men gave up on Humpty, so they handed the problem off to Engineering."
5 comments
Top Comments of the Week
Like Us on Facebook

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)
EE Times on Twitter
EE Times Twitter Feed
Flash Poll
Radio
LATEST ARCHIVED BROADCAST
David Patterson, known for his pioneering research that led to RAID, clusters and more, is part of a team at UC Berkeley that recently made its RISC-V processor architecture an open source hardware offering. We talk with Patterson and one of his colleagues behind the effort about the opportunities they see, what new kinds of designs they hope to enable and what it means for today’s commercial processor giants such as Intel, ARM and Imagination Technologies.