Do you recall how I always harp on the notion that the documentation should be etched in stone before the first line of code or page of schematic is created?

The point is to get developers to go back to applying engineering principles to the process of engineering. As software practices, applied to firmware and, to some extent, hardware via HDL's, have become pervasive within the development culture, rigor has gone out the Window(s).

Consider, for a moment, the mental image one gets of a "hardware engineer". You probably see a middle-aged guy with a short haircut, glasses, and a short-sleeved white shirt, neatly pressed pants, and wingtips. Now consider the term, "software engineer", which is essentially an oxymoron. You'll probably envision a youngster with unkempt hair, dirty jeans, and a t-shirt with his necktie printed on the front of it, holding a can of "Jolt" or "Red-Bull", wearing sneakers, probably not fully laced, with his ears wired to an iPod.

The problem isn't that people don't design their hardware well, nor is it that the "software people" don't do their jobs equally well. The problem lies in that managers don't perceive verification and testing as terribly important, (It's the WalMart syndrome), and that the documentation process that leads to good specifications against which a product can be tested is burdensome and costly. The result is that they don't want to pay the people who perform those tests, and they don't want to buy the equipment that will make their testing effective.

The WalMart syndrome is the result of WalMart's policy that their suppliers must reduce their cost to WalMart every year, else they'll lose WalMart's business. The first year the suppliers cut cost by every reasonable means at their disposal. After all, they've already done much of that since they have to survive in a competitive market. The next year they start to make unreasonable cuts, and the first thing to go is quality control. Of course, the next thing to go, as a direct result, is quality. It's cheaper, after all, to print a nice warranty and let the end-user do the "verification and testing." The result is that we all suffer a subsequent loss in standard of living, since we can't get any tested and verified products any longer. The WalMart syndrome pervades the entire marketplace, after all.

The reason for so many open personnel requisitions in the verification and testing field is because that department sees less money than other development areas, AND, gets the promotions, etc, last. When a new product is released, nobody pats the test guys on the head and says "attaboy!" When RMA's start to show up, it's the test guys who get called on the carpet, with "Why didn't you catch this problem ...?"

I know this is a sore point with you and others in this forum, but ...
Let me give you a typical example of this breakdown.

There's been lots of chatter over the years about various "RESET" problems with 8052-type MCU's. I've frequently asked people to indicate why they believed this class of problem to be a RESET problem rather than some other problem, e.g. slow Vcc rise time, or the like. Has anyone ever offered a rigorous identification of the problem? NO!

The best anyone has offered is, "Well, I added a supervisor IC, and it "fixed" the problem. I ask you, "In what way does that reflect any rigor?" Where's the evidence that the problem was identified and addressed. I submit to you, Erik, that it was not.

I know what the boss wanted was to make the problem "go away." Statistical evidence that it has done so is certainly more than enough for the boss. Shouldn't there be more rigor in the engineering process, though?

Now, when this sort of method is applied, who gets the "pat on the head?" It's not the test guys. After all, it's their job to apply rigor. When nobody cares about rigor, nobody appreciates good testing and verification. The result: Nobody really wants to be one of those test guys. They always bear the bad news, after all, and seldom the good news.

RE