Reflections on Technology Product Quality
Table of Contents
On Hardware Quality
It is impossible to test quality into a product. Quality must be designed into the product.
- The hardware designer is always responsible for the production yield. The purpose of production tests is to check production quality, not product quality.
When the prototype fulfills all marketing requirements, you are only 40% done
- The remaining 60% is spent transforming the prototype into a producible product.
Analog Design Advice
Always treat “analog ground” as a signal.
- The only connection between analog ground and power ground/digital ground should be through one resistor. Design for a 100-ohm resistor and mount a 0-ohm resistor.
Always expect that external connections will introduce ground loops if possible
- Remember that a varying magnetic field will induce an electromotive force in the ground loop. This force is proportional to the area of the loop. Remember to check for ground loops internally (on PCBs, through wiring harnesses, etc.).
Shielded cables are no help against electromagnetic interference.
- Use balanced transmission and twisted pairs of wires to eliminate electromagnetic interference.
Digital Design Advice
Digital signals must be treated as analog signals when sent over long lines
- A long line is a wire or trace that is longer than l=tr·c·n, where tr is the minimum rise time of the signal, c is the speed of light and n is the correction factor for physical wires (usually about 0.67).
Always terminate long lines
- A long line is defined above. The necessary terminating resistor is usually in the range of 100 – 120 ohm.
Be extremely careful when moving between clock domains
- Setup and hold times can usually not be guaranteed when doing so.
On Software Quality
It is impossible to test quality into a product. Quality must be designed into the product.
- !
Module Design Advice
Always document all available entry points into the module in the module design document and have it reviewed by the rest of the project software staff.
The first and foremost requirement for a piece of code is that it is readable. Obscure and tricky code is impossible to maintain and often contains hard-to-find bugs.
“C” Programming Advice
Always declare functions and variables that are internal to your module as “static”
- That way, nobody else can bring havoc to your internal module structure.
If at all possible, never use or publish global variables
- If somebody wants to know the value of one of your internal variables, write a “member” function to return an official value of that variable.
Understand and use type qualifiers (const and volatile)
- The const qualifier tells the compiler that the variable should not be modified. The volatile qualifier tells the compiler that the variable may change outside the current compiler scope. All global variables should be qualified as volatile.
From MSDN:
- The const keyword can be used to modify any fundamental or aggregate type, or a pointer to an object of any type, or a typedef. If an item is declared with only the const type qualifier, its type is taken to be const int. A const variable can be initialized or can be placed in a read-only region of storage. The const keyword is useful for declaring pointers to const since this requires the function not to change the pointer in any way.
- The compiler assumes that, at any point in the program, a volatile variable can be accessed by an unknown process that uses or modifies its value. Therefore, regardless of the optimizations specified on the command line, the code for each assignment to or reference of a volatile variable must be generated even if it appears to have no effect.
- If volatile is used alone, int is assumed. The volatile type specifier can be used to provide reliable access to special memory locations. Use volatile with data objects that may be accessed or altered by signal handlers, by concurrently executing programs, or by special hardware such as memory-mapped I/O control registers. You can declare a variable as volatile for its lifetime, or you can cast a single reference to be volatile.
- An item can be both const and volatile, in which case the item could not be legitimately modified by its own program, but could be modified by some asynchronous process.
All code should be passed through lint. Every remaining lint warning should be commented on.
- A lint code checker is an excellent tool for discovering subtle bugs in the code.
Common “C” Pitfalls and How to Avoid Them
Always test pointers for NULL before using them.
- Otherwise, you are likely to either mess up the interrupt vector table or cause a fatal access error trap.
Be extremely careful when decrementing unsigned types
- If an unsigned variable has the value 0, decrementing it will result in a large positive value!
Always use parentheses in complex expressions
- Otherwise, the compiler will interpret the expression according to the precedence rules – and those are not obvious.
On Management and Product Quality
Be very careful of what you wish for – you might get it
- If you want a lower component cost, you might get it – at the expense of increased service and guarantee cost.
Reorganization never solves anything – it just adds to the confusion
- First observed in writing 400 BC by the governor of a Greek province.
Product failures due to user errors are just as real as product failures due to equipment fault
- Remember to budget for understandable manuals and idiot-proof human interfaces.
The purpose of project documents is to ensure product quality, not to satisfy some administrative need.
- Insist on quality in the project documents from the project staff. Purely administrative documents are your responsibility and should never be delegated.
Discourage “quick fixes”.
- The only “quick” thing about it is the introduction of new bugs.
Read my next article https://www.physicsforums.com/insights/time-synchronization-across-switched-ethernet/
Master’s in Mathematics, Norway. Interested in Network-based time synchronisation.
Nice Insight @Svein
[QUOTE="Svein, post: 5517049, member: 538805"]Not in the consumer market, probably. But would you feel comfortable in an oceangoing boat where the final test fallout were 10% or above? Or, for that matter, in an airplane with similar production problems?[/QUOTE] Of course not. My background is in nuclear plant controls which are even more stringent. But the Insights article didn't say that it was limited to critical applications, while your advice on how to achieve product quality does applies to all kinds of software. My post was not criticism, it merely pointed out that we shouldn't look down our noses at low quality in every domain.
[QUOTE="anorlunda, post: 5516493, member: 455902"]I just wanted to point out that product quality is not always the most important feature.[/QUOTE]Not in the consumer market, probably. But would you feel comfortable in an oceangoing boat where the final test fallout were 10% or above? Or, for that matter, in an airplane with similar production problems?
I think there is some validity to the notion that the public is not always interested in quality.Good article, congratulations. But let me present an different view on the value of product quality.Consider the phone apps subset of the world. Perfection is wasted on an app that people don't want, and defects are not sufficient to defeat a popular app.Think of AT&T phones from the 1970s. They were top quality, and built to last for 40 years. Who wants to pay for that quality today? Today's consumers are anxious to throw away our smart phones after a year or two so that we can get the newest versions with extra features. Reliability, ruggedness, longevity, maintainability, and repair-ability are all deprecated in the modern smart phone market. Bugs in the software are simply patched at the next forced update.I think that the buying public is suspicious of claims of additional quality justifying higher prices. Audio cables are a good example. Scam artists exploit false claims of quality (as well as every other falsehood they can imagine), thus turning customers into skeptics. I'm such a skeptic. I find that often (not always) I get the best value for my money at the dollar store.None of these things dispute what you said in the Insights article. I just wanted to point out that product quality is not always the most important feature.
[QUOTE="Dr. Courtney, post: 5513406, member: 117790"]So while I agree that you cannot test quality into a product, testing can certainly determine that the design has not yet achieved the level of desired quality.[/QUOTE]I remember – a lot of years ago I was with Tandberg Data. One division was producing tape streamers and had put much effort in the design. They then told a Japanese customer somewhat proudly that their yield now was 99.95% (i.e. 0.05% failure in the final tests). The customer responded with: "Congratulations! You are now #3 on our lists – from the bottom!".The result: One of the leading hardware engineers was given the responsibility to fix the product quality and the production quality. It took two years of intensive work, but they ended up as #3 from the top.A digression: In another context (where I was a consultant), I learned that the main product had a 40% failure rate in the production test. My response was: "Are you kidding? How can you live with such a bad product / production quality?" Needless to say, they were offended and told me to keep my opinions to myself…
It is impossible to test quality into a product. Quality must be designed into the product.Reference https://www.physicsforums.com/insights/reflections-product-quality/Some years ago I was the main RF test guy at Cisco Systems. I developed an automated test system that provided both the factory floor tests AND had a superset of those used for design validation.During the design validation phase of many products, there was a running discussion/debate with the design engineers whether what my system was reporting represented design flaws or manufacturing flaws in exemplars of the early design. I was under constant pressure to tweak the system to PASS the product so we could get it to market quicker. My refrain was, "Let's fix the product, not the tests." The tests, while often complex, were a relatively straight forward implementation of testing to the specifications set out in the design goals.So while I agree that you cannot test quality into a product, testing can certainly determine that the design has not yet achieved the level of desired quality.This is an important point, because the design engineers often wanted to argue that a given specification need not be tested, claiming that it was "guaranteed by design." I often answered, "If it is guaranteed by design, then why does it keep failing the test?" Eventually, I took the philosophy, "If it has not been tested, then it does not work." This is not an absolute truth statement, just an expression of my conviction that a company needs to test product to ALL their specifications before they gain confidence things are working as designed.The hardware designer is always responsible for the production yield. The purpose of production tests is to check production quality, not product quality.Reference https://www.physicsforums.com/insights/reflections-product-quality/The distinction between production quality and product quality is somewhat artificial, and completely artificial from the customer's perspective. What he buys either meets the specs or it doesn't. He doesn't care why, nor should he have to.There are inevitably design flaws that do not show up until the product is mass produced near or at full volumes. Other design flaws may not show up until production is moved from one factory to another, because only then is a design sensitivity to some manufacturer detail that was thought insignificant revealed.At the same time, the notion that the hardware designed is always responsible for the production yield ignores some of the nonsense and noncompliance that can occur on the factory floor, as well as some of the quality issues that can occur with components suddenly out of spec.When the prototype fulfills all marketing requirements, you are only 40% doneReference https://www.physicsforums.com/insights/reflections-product-quality/In my experience, people in a company tend to think of the "real" marketing requirements as the subset of the engineering specs they think the customers really care about; whereas, I always thought about them as the complete engineering spec. The motive was often to have an excuse to ship product that fulfilled what "customers really want" that may be out of spec in areas that "customers don't care about." In cases where this dichotomy exists, one needs to distinguish between the complete engineering specs and the "marketing requirements."