At first I thought the news reports of EFTPOS systems at a bank here in Australia not working with a ‘Y2K’ type of bug on New Year’s day were exaggerated – but the article in Tuesday’s Sydney Morning Herald Welcome to 2016: EFPOS Glitch Spreads points to a wider global problem. As soon as I read that 2010 was being interpreted as 2016 by the EFTPOS terminals I knew that the old HEX system was at the heart of it. But why? It is such an obvious thing to test for. Is ‘programming’ so easy and intuitive these days that some of the fundamentals are ignored? A rhetorical question maybe – but as someone who had to debug program dumps in octal I used to cringe at the thought of expanding my arithmetic literacy to HEX – adding A-F required a bit more mental agility than good old 0-7. Back then I thanked my lucky stars that I wasn’t working on the mainframe.
So what are some of the lessons learned?
Testing - Whether the bug was caused by the software itself at a code level or by interface protocols being incorrectly aligned doesn’t matter. The main issue for me is why wasn’t either scenario included as part of a testing plan? Have we gone so far with our ‘plug and play’ open interfaces that we assume one side of the plug is OK? If so then what are the specs?
Backup systems – well for this problem taxis are still very competent with the old ‘paper in the machine’ system – their electronic systems are regularly (and conveniently) out of order. Ever noticed that? Well, it seems that normal EFTPOS systems are so reliable that most people don’t seem to have the ‘old way’ on hand any more or staff trained in how to use them. I also expect the back-office paperwork and additional time just to get paid is also a significant disincentive and maybe this function has gone by the wayside as a cost saving measure.
Other commentary from an article in wmexperts Year 2016 bug plaguing text messages? on the issue points to a possible binary to hex misalignment:
| 010110 is binary for 22 not 16 But you are correct that 10 is 16 in Hex. Submitted by gus (not verified) on Fri, 01/01/2010 - 19:50. • reply 010110 = 16 using binary coded decimal. but should be written as 00010110 Submitted by Anonymous (not verified) on Fri, 01/01/2010 - 20:24. Oh okay I see what you mean. 010110 in binary is 16 in Hex. 0001 0110 = 1 6 or 16 Hex |
Anyway, whatever the cause and domino effect the fact remains, in my opinion, that a fundamental building block of software, ie the use of codes (and/or notation), was not tested.
I am flabbergasted because so many of these types of issues have been known for so long they should not occur now, for example managing a divide by zero which would crash a system or doing all arithmetic in integer and cents because floating point would create non-reconcilable numbers. That was why you did it – it was just coding practices from experience.
What else can I say – I am lost for words that in this day and age such obvious errors can occur and I’m glad that I’m not accountable [for IT divisions] anymore ?.
Hot off the press – bug now fixed! Back from the future: normal Eftpos service resumes
The post 2010 or 2016???– A HEX on you! appeared first on International Blog.
