How mighty are the fallen! The apple debacle root cause could stem from too much reliance on automated testing and secrecy.

The problem with the hand position inhibiting the RF connection should have been seen easily with normal use. Why didn’t they see that?  Testing with automation gives management great warm fuzzy feelings when multiple test suites run without error each night. That run is supposed to catch all types of software errors including network connection issues. Testing like that does not consider real usage. It only catches problem the testers and programmers can imagine. Problems by their very nature attempt to hide from testing. They seem to be sly devils that require dedicated curiosity driven testing to uncover.

Inhibiting the signal by placing a some thing over the antenna has been seen before. Do you remember the issue Buick had with it’s first radio antenna embedded in the windshield? The antenna worked well in the lab and got good reception but no one considered how it operated while the windshield washers were on. Result fuzzed out reception. Sound familiar? It was tested but not in a real world environment just like Apple.  The problem escaped because the individual component was tested in isolation. Now the antenna is still in the windshield but it has been moved above the wipers. If Apple was smart they would move the appropriateantenna strip to the top of the phone. We don’t grab the phone by the top and bottom of the phone so the same cure could work for them too. Much easier moving a physical device around in car compared to redesigning the innards of a cell phone though.

Next problem is the signal strength indication. Some thing is definitely sour in their description of the issue as a software issue. Somehow the calculation for the signal strength display is just plain wrong. So when you press the side of the IPhone case the signal strength isn’t really changing it’s just the meter that’s bad. Bunk! If the meter is bad the network connection should not be dropped. The only way it might make sense would be if the signal strength calculation was done and stopped the phone from trying to make the connection. The same calculation was set up in the earlier Apple phones but somehow it wasn’t a user issue. Hmmm. That just doesn’t sound right.  They might have  changed the antenna design and forgot to change the signal calculation to go with it.

The same style of issue happend with the Ariana rocket launch. They inherited code from an earlier system into the new system without doing a dry run testing the software on the new system.  It was deemded to costly to run.  Remember this little software bug?

Ariane 5′s first test flight (Ariane 5 Flight 501) on 4 June 1996 failed, with the rocket self-destructing 37 seconds after launch because of a malfunction in the control software, which was arguably one of the most expensive computer bugs in history.^[10] A data conversion from 64-bit floating point value to 16-bit signed integer value to be stored in a variable representing horizontal bias caused a processor trap (operand error)^[11]because the floating point value was too large to be represented by a 16-bit signed integer. The software was originally written for the Ariane 4 where efficiency considerations (the computer running the software had an 80% maximum workload requirement^[11]) led to 4 variables being protected with a handler while 3 others, including the horizontal bias variable, were left unprotected because it was thought that they were “physically limited or that there was a large margin of error”.^[11] The software, written in Ada, was included in the Ariane 5 through the reuse of an entire Ariane 4 subsystem despite the fact that the particular software containing the bug, which was just a part of the subsystem, was not required by the Ariane 5 because it has a different preparation sequence^[11]than the Ariane 4.

Credit (Taken from Araina 5 Wikipedia site.) 

Apples penchant for secrecy in their releases also work against them for this type of issue. Real world issues can only be found under uncontrolled conditions. Keeping the phone secret under the Apple way contributed to this error. It would be very interesting to see if this issue was discovered internally to Apple and then ignored or dismissed by management as a non issue. We will probably never know if management or testing let these bugs out to the consumer. 

Summation:

Too little real world testing.

Too much reliance on automated testing instead of real world testing.

Possible coverup about the real issue.  Management reasons for the problem just doesn”t add up.

Working on a phone for TIM (an Italian service provider) a little info snuck out the door. It seems the phone had the ability to store up to 5 minutes of voice messages internally. The service provider got wind of it and went ballistic. It seems they charge for storing voice messages and this little application was really going to cut into their profit. Motorola could not just pull it from the phone it had been broadcast throughout the net.

They took a different approach. Instead of removing the application they crippled it. First the record time was reduced from 5 minutes to 2 minutes. Effectivly making it useless. Then the controls to enable the function were buried very deep into the phone in an unrelated functional tree. It was there but the method to command the function to turn on was not recorded in any online manuals. 

Result all the time and effort to create a phone bound solution to the voice message problem was thrown out.