Strange ATM / Cash Card bug?

I recently had a cash card from a major UK bank.

I used to put it in any ATM / Cash Point, punch in my pin, and get access to the services. I used to be able to draw statements and check my balance. But as soon as I tried to draw money, immediately the machine would eject my card and give me the error message "Temporary error processing your request. Please try again later". No matter which machine or bank I tried, always the same result.

A while ago, friends of mine in that space told me about the ATM / Cash Point algorithm. And the only really significant thing that I remember, is that the machine only actually authenticates your pin against your bank once you select the service that requires authentication... eg balance request, mini statement, draw money.

So...what was going on? I have thought about it for a while now, and still no idea. When I eventually contacted my bank, they told me not to worry as clearly the faults I was experiencing were temporary faults that existed only the Cash Point machines. Yet all my data points told me something else was happening. Eventually the "helpful" call centre operator suggested I just get a new card. Which I did, and it did solve my problem.

I can only think that there was a "magic sequence" of numbers encoded somewhere in the chip / magnetic strip of that particular card which was causing a very nasty bug on the various Cash Point hardwares/softwares to show itself. Lucky me.

Or unlucky them...could such a magic number really exist somewhere and be used somehow to cause a buffer overflow attack on what I've pretty much taken for granted is a well and truly stable set of components and systems after all these years?

These kinds of puzzles is why software, software engineering and software quality will always keep me interested.

What's Up With All The Cynicism in IT?

At SPA2009, I had a little session titled "What's Up With All The Cynicism in IT?". It was unfortunately quite time reduced from my original plan, but I did manage to impart a little knowledge of Edward De Bono's Six Thinking Hats method to a group of 8 varied participants, who did supply quite a bit of "food for thought".

I've published my presentation, and the outputs of the group work sessions on the SPA2009 wiki: What's Up With All The Cynicism In IT? Outputs

WikiLeaks - Oops!

Wikileaks is a very interesting little web site that came to my attention because of some sensitive documents that were leaked in/by South African affairs recently. Some very interesting cartoons, names and documents, from some the most ?unlikely? people and countries I would not have guessed at.

Light Motivational Relief

Despair.com for wonderful miscellaneous motivational posters and sayings....all twisted into a very cynical viewpoint. It is a really good laugh!

Best Practice Applied In Wrong Context - Example 1

A friend of mine was ranting the other day. He had just done an iteration retrospective with his development team wherein they took a look at their quality metrics and discovered that "quality" had actually dropped off even though his team had spent more time than ever before on the client's official Quality Process.

I discussed this further with him and we agreed that quality is a mostly subjective concept when it comes to software ... we agreed that it can't be objectively meaasured ... we agreed that it can't be artificially injected "to meet the required metric" ... we agreed that it is something that Software Quality Assurers infer based on monitoring the various metric trends that make sense in the particular environment/context that the software is being developed in/for.

So with all this agreeance I asked him to explain further.

This story is probably a symptom of why I think there is so much cynism in the software industry. Read on if you dare!

It turns out that the client has a well worked out, well defined Quality Process that they are extremely happy with. This Process is guaranteed to prevent massive loss of life/income/spiralling out of control costs/etc etc - you can imagine why a large company invests huge amounts of time and money in creating a bullet proof Quality Process: manage risk, whatever that risk is.

Okay ... so why is my friend ranting? His team followed the process, passed a bunch of procedural milestones apparently and everyone was happy. Yet when he and his team look at the metrics they defined for how they measure quality, they noticed that the number of issues had risen, that some important tests had not been run early enough in the iteration to find issues that they could then respond to before the end of iteration. There were known open issues, and the were issues that had been addressed, but had not been signed off. There was waste accumulating that had not been a problem before.

How did this happen? The people whose responsibility it was to run the tests, to provide the early feedback had been too busy ensuring the team met the Quality Process requirements - they had been documenting, and reviewing and getting documentation reviewed and spending a large amount of time away from the product they were responsible for delivering. They were going on a tangent from users' needs.

And it showed.

There is no happy ending here - key client representatives (project stakeholders, but not users) have to ensure that their organisation's process is followed. Even if they know, and everyone else knows, that the process is not adding value, and that indeed, as above, the process is actually diminishing value. And it appears often that several times a group of client representatives need to experience failure and pain before they will attempt to address a badly formulated, or in the example above, placed, process. Sometimes, regrettably, these lessons are learned during retrenchment phases.

Yuck!