BBC Clock Inaccurate - 100 Days To Fix?
mikejuk writes "The BBC home page has just lost its clock because the BBC Trust upheld a complaint that it was inaccurate. The clock would show the current time on the machine it was being viewed on and not an accurate time as determined by the BBC. However, the BBC have responded to the accusations of inaccuracy by simply removing the clock stating that it would take 100 staffing days to fix. It further says: 'Given the technical complexities of implementing an alternative central clock, and the fact that most users already have a clock on their computer screen, the BBC has taken the decision to remove the clock from the Homepage in an upcoming update.' They added, '...the system required to do this "would dramatically slow down the loading of the BBC homepage", something which he said was "an issue of great importance to the site's users".
Secondly, if the site moved to a format in which users across the world accessed the same homepage, irrespective of whichever country they were in, it would be "impossible to offer a single zonally-accurate clock."'"
I'm not sure I can trust a source which says "it has been stated that it would take 100 programmer hours to fix" then quotes a paragraph stating 100 staff days. Regardless it is harder than it looks: the BBC doesn't want to get into the business of running a time server, nor trying to automatically determine which time zone any particular visitor to the site happens to be in (by, what, IP address tracing?).
No kidding!!! What do you say at this point?
It took one large Luxembourgish bank nine months to change SUPPORTED_OS = MAC into SUPPORTED_OS = Linux32 in a configuration file in a jar named LuxTrust_Gemalto_CryptoTI_Adapter_LIN32_1.4.jar (yes, they did indeed accidentally put the Mac config file into the Linux jar... it's that stupid...)
Another bank is celebrating the first year anniversary of this same bug right now as we speak :-) (unfixed yet, of course)
Reason for the slowness (in both cases): when fixing such a mixup, according to their procedures, the entire test suite (... which incidentally, didn't catch this bug in the first place...) needs to be re-run, and this takes weeks, and so they shy away from the expense.
So we end up in the paradoxical situation where the presence doesn't reduce the number of bugs seen in production, but actually increases it. Rather than catching bugs early, the test suite instead perpetuates existing bugs...