Mushware while defining a product is one thing, Mushware while promoting a product is something the developers cannot do anything with.
For example way back in 1990s , we developed an interactive TV with a bulit in co-processor having the capability of storing small BASIC programs. This was basically aimed at school going kids to learn programming techniques with simple programs.
Our marketing team hyped this feature to such an extent that they sold one of ourr TVs as an Accounting system to one shop keeper, telling him that he can program his TV to store all accounts for his business.
We had a very hard time in answering the after sales querries of this shop keeper on how many accounting entries his TV could store and so on and how can a printer be attached to the TV to print his account books!
Marketers do not "lie"; engineers just "cannot do their jobs". I have worked several jobs where everyone had "done their job", made the company money, and all we engineers had to do is just deliver the product before we leave for the day. Most times engineering has always been the bottleneck when creating that new little feature that was needed to sell the product. Joke example: a nuclear submarine company's engineers could not make their hatches fully compatible with the International Space Station's air locks and then keep making excuses about not being able to do a full scale onsite test at the ISS to show the customer this little feature that clinched the sale >;-). You have not enjoyed engineering until you have a meeting (with sales, marketing, and management) and finally find out what the product really does just before it ships.
@Esterline Research & Design Marketing, like engineering, is a profgession with specific skill requirements. Too often people assume that mushware is the way to sell products. Well that is true for some dubious products, provided that there is no intent to foster a long terms customer re;ationship. Note that I'm NOT advocating sleezy techniques, but I do want to recognize that mushware techniques do work for most people some of the time.
I'm sure that all of us cn think of technology companies that deliver what they promise with a minimal amount of hype. These enlightened companies use marketing to make the facts speak FOR them - and they tend to have strong customer loyalty providing that the products do what they sayh.
@prabhakar_deosthali I used to teach a Software Project Management course in the 1980s during which I purposely had some mushware included as part of a problem statement. About 10% of my students called out those statements as problems for their planning process.
Leaving mushware in product specifications is an open invitation to disaster. It might cost you your job, but ignoring the problem will not allow engineers to make a product that meets the needs.
Having said that, there are times when nobody can be specific enough during the initial description. In these cases, it's time to take a page out of Lean Startup strategy to actively learn what is real - prospects often mean something different that what you heard.
@TFCSD Old school product development still relies on the "waterfall" model - you know, the one where the big, bad, explosion happens when the product is finally "released." Fortunately I've mostly avoided these conflagrations by insisting on what is now called an Agile Methodology.
In the early 1980s working on the IEEE Software Engineering Standards subcommittee, it became painfully apparant to those of us working on the Software Unit Test Standard that the waterfall model was a high risk approach to product specification and design. We discussed product specification alternatives using a "twisted pair" metaphor as an alternative to the waterfall model. Now thirty years later much of the entrepreneurial community has latched on to the concepts that were formulated to address the weaknesses of the atomic bomb approach to development - "all or nothing."
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.