A couple of years back, my wife and I remodeled our kitchen. In the process, we replaced our oven and range with a Kenmore Elite slide-in unit, similar to the one in the picture below. My wife was pretty nervous about buying an oven with a display and a keyboard–because she understood that meant embedded software with its all-too-frequent crashes and upgrades. At the time, I assured her that oven controller firmware was the sort of thing anyone who could spell ‘C’ could write.
But now my day of reckoning has come. Our 3-year old oven isn’t working properly. It even failed my wife on Christmas Eve, as she prepared a meal for about 20 family and friends. (Praise be for a full tank of gas and a 3-burner outdoor grill!) But still I felt vindicated. Our oven problem was with the electronics not the firmware, I assured her–as if that were some great thing in itself! The problem only occurred when the oven was hot. And a power-cycle didn’t cure it. We have learned that the buttons and display will work again, eventually, after the heat has dissipated.
Today the repairman is here. (I didn’t dare void the warranty by peeking at the electronics inside before he came.) “What error code does it give when it fails?,” he wants to know. “F-1-?,” I reported quickly. “We can’t read the last digit, because that’s a part of the display that doesn’t work when the oven fails in this way.” “Hmm.”, he muttered, turning to his repair manual, “the fix for F10 is as different from the fix for F19 as for every error code in between.” “Can’t you hook up your laptop to the oven’s diagnostic serial port?,” I wanted to know. “Nope,” he replied, “The display is the diagnostic port.”
Crap. My wife was right. Writing the embedded software for an oven controller is harder than I thought. The designers of the Kenmore Elite slide-in electric range’s firmware forgot to account for the fact that they only had one diagnostic port and that it itself might break. Or they knew it and cheated their customers (including us), to reduce the BOM cost, out of a serial port we wouldn’t know we didn’t have until it was too late. Either way, shame on them.
This should be eye-opener or wake-up call for such 'Crap' makers!
Just check this link:
http://cacm.acm.org/magazines/2010/1/55760-what-should-we-teach-new-software-developers-why/fulltext
I just finished a stint managing a Value Engineering group – essentially assessing an entire product to remove cost. BOM, manufacturing cost, etc. Assuming the original stove *did* have a secondary debugging interface, removing "duplications" such as this is common. Engineering teams really have to fight with strong justifications to prevent changes like this (engineers don't generally initiate these cost reductions), and they often don't win. Costs to fix downstream quality problems like yours aren't factored into the equation because short-term, they don't exist.
To Lisa's comment, you may arrive at the same answer if the cost of fixing downstream quality problems is accounted for. It is difficult to estimate, though, because you are comparing two numbers, each of which is the product of a really big number and a really small number. On one hand, you have units shipped (large) times incremental cost (small). On the other, failure rate (hopefully small) times cost to repair (very high). Note the paradox: the more reliable your product is, the lower the cost you can justify.
i have that same oven
– had the repairman come once after a few years like you. fortunately it was only a fuse (i think). i had the keyboard go on the matching dishwasher, because the product design doesn't have a gasket or water seal around the keypad, so make sure you don't have wet hands when you push the keypad on the dishwasher; i also had to replace the thermal overload last week apparently it may be undersized (design).