Your comment also leads to the subject of metrics imposed on engineers. There is of course, a big difference between quality code that does the job but is poorly documented, and lousy code that is well-documented. There should be a happy medium, but that is not always comprehended by metrics...and perceived quality of the engineering effort.
Engineers know quality when they see it. Managers and metrics keepers, not always...
Good points above; but what really upsets me is when product quality is sub-par right off the bat, and I think we, firmware developers, are partly at fault here as well. The bean-counter and "Time to Market is King" attitude of management is a drag for sure; but would everything be perfect, if we were given a Groundhog Day chance to get things right? When Jean Labrosse, the creator of uC/OS, wrote an article after this year's ESC about his coding convention, he was literally ridiculed for liking his comment-closing star-slashes right-justified (hey, are all the ISO-9001 requirements any more justified, no pun intended...? :-) ), while completely disregarding his excellent point about the importance of proper code documentation. The "preamble" preceding every function, providing 1-sentence pithy descriptions of the function's purpose, the input parameters and the return value, is the most obvious and effective way to improve code quality, IMHO; and yet, is it being done religiously? I don't think so! Within the first week of their existence, these preambles save more time than it took to create them, even if a single developer is working on the code. You will be surprised how many times I recognized inefficiencies, under-specification and flat-out logic flaws in my design, just because I forced myself to write down the above info verbally before churning out the code like a snow cannon.
Of course the flip side of the coin is the self-interest in producing obfuscated code. While I don't believe for a minute that it really means job security [management, if they have even the slightest spark of insight, should get rid of the notorious trash-coders], I can really see how people (completely unknowingly) form an impression that because a code is simple, clean and reads like a book, it must have been very easy to develop as well. I would still argue, however, that proper coding habits are a win-win-win situation, and are in the best interest of everybody.
It comes back to the old adage, "you get what you pay for." In consumer electronics, most customers, including the end consumer, are not willing to pay extra for high quality or reliability. If X additional BOM cost would extend the product life by Y years, but lifetime revenues for the product would be reduced due to lower market share and lower total sales, then a prudent business manager would be foolish to agree to spend an extra X dollars on BOM cost.
Most companies draw the line at safety issues. They do not buy exploding lithium ion battery packs just to save a few cents per unit -- for the same reason that food distributors don't buy milk that has been diluted and tainted with an industrial protein in an attempt to cheat the quality test.
Causing your customers to replace products more frequently due to poor quality is one thing. Harming them is quite another. But again, in the end it comes down to "you get what you pay for." Most consumers are willing to pay for freedom from harm -- not as many are willing to pay for longevity of performance.
I think we had a similar discussion on the topic of degrading quality, may be a month or a couple of months back. If I recall correctly, majority of the readers agreed that they thought that there was a trend of degraded quality and that was mostly because the management were not allowing enough time due to market pressure. The result of this survey described in this article supports the same.
How to fix it?...tough question. At this moment I can only think of a way, which could be to enforce certain norms for mandatory quality requirements internationally for categories of products…but difficult thing to do. Again, the question can be raised whether we need a phone that would be functional for next 10 years? I think we will change our electronic gadgets every 3-4 years, if not earlier, because of the new things coming so fast. But for a phone, the quality norms might enforce health and safety requirements for user at the minimum.
I think you hit the nail on the head with this reply. I find it interesting that we have blue ray DVDs but a large number of people that have HD TVs are happy streaming videos that are better then NTSC but are a far cry from blue ray DVD quality. Shows that we can make stuff that is better then a large portion of the population seems to want.
Who runs the company? Bean counters or the Engineers? The engineer, my vote - would put forth a better product if given the time....Bean Counter - Time to Market takes precedence. Can you say "Sales commission check"? This will repeat until one entity says enough is enough - The Customer.
Although I would like to produce a perfect design in both function and quality, I have accepted that even my own requirements are not "frozen"(never happens, does it?)long enough for this dream to be realized.
So, for me, quality is just another variable in the equation - not an absolute. This axiom is rolled up in a poster that I saw on a machinist's office door: "Cheap,Fast, or Good - pick any two of these that you want!"
Now, before you say "I hope this guy is not designing pace makers", I think that most of us (including me) will lean more towards "Good" than cheap and fast. Perhaps that's why we see a Quality Crisis?????
Complicated issue. Sometimes what works best is what is "Good Enough" for the "Right Price". Case in point, if you buy a higher priced Cordless drill that might last you 10 years, but the battery pack is worthless in 4 years, and the cost of a new battery pack is 3/5 of a new drill. Does it make sense to buy the more expensive drill and then later a new battery pack or a cheaper drill initially and then to get the new drill (which may be a higher voltage, have more torque, have a new warranty,etc...).
We are right to want to build a good product (and consumers are right to want a good product). The question is, how good is good enough and at what price ?
I will second Kevin's comment, but add that the use of counterfeit components (ones that really are marked and packaged to look like what they are being used to cheaply, in all senses of the word, replace) is a new phenomenon that was not seen until China. Before China we always had the manufacturing group that tried to substitute a cheaper component into the BOM, but now have absolutely no control or traceability on our designs manufactured there. In the past couple of years on my projects I have seen OpAmp relaxation oscillators that did not oscillate, exploding ceramic capacitors, and numerous other less than shining examples of circuits designed and built in the US that always worked, then sent over to China and never worked when built there. I for one will not buy food or cooking equipment that is manufactured there due to my real concerns with materials substitution and introduction of unknowns when the specified materials are short. This has made replacing my good US made cookware and tools pretty tough lately, and for lots of extra time inspecting the seafood pacakages.
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.