Before I start I just want to say that much of this post is mere speculation on my part and not specifically targetted at Currys. They just happen to be the catalyst and example for this post.

A few months back I ordered a new tumble drier online from Currys to replace an aging one that my family have long outgrown and chose Currys purely because they were selling the model I wanted at the cheapest price that I could find online. No problems with the transaction (or the service that was to follow I hasten to add), but what I did find quite interesting was the confirmation email that I received shortly after placing the order.

On the email that I received, under the order breakdown there was a typical information section that looked like this:

I kid you not, on the “Before we leave” bullet point there are 11 apostrophes for the words we’ll and you’re. You can also see similar issues in two other places in the text. I’ve often come across bugs in my career where I’ve seen 2 or 3 single apostrophes in some data but never 11 in one hit!

I do always raise an eyebrow when seeing issues involving duplicate apostrophes.. In the db world that would more often than not be indicative of  some kind of string concatenation going on or incorrect logic somewhere replacing single apostrophes with two single apostrophes to make it into a valid statement for SQL rather than using parameters. All in all, a prime target for SQL injection based attacks. But to be fair though this may have nothing to do with SQL or whatever RDBMS Currys use.

Alternatively Currys could be suffering from a problem that many large businesses do where their systems have rapidly and organically grown over the years. These businesses tend to have a whole number of interconnected legacy systems, apps, imports/exports, 3rd party connections, BI etc etc and changing anything significant in the core is just too costly and time consuming and that is not factoring in any knowledge long lost with the sands of time. Instead they just keep adding around the edges here and there to get the functionality they need to have in rapidly changing market place. They need to get new features to market quickly so they can ill afford complete re-architectures of legacy systems. As such from time to time you get strange things like the above happening as the logic/data is going through so many legacy apps/tiers before it finally makes it out and debugging it is a nightmare. I have seen this problem a number of times at previous organisations I have worked at.

Sometimes though businesses do need to bite the bullet and sort things out when they get to this stage. Legacy applications do tend to be very reliable as they have been tried and tested for years and years, but I doubt that many of them would stand up to a modern day targeted attack. Current software security patterns and encryption methodologies just didn’t exist a decade ago. Any encryption technology used when the software was originally developed would seem primitive now by todays standards. The problem is often made worse because the legacy systems tend to only run on old operating systems because they can’t be upgraded to a newer OS thus increasing the risk of a breech.

It is very hard when developing something today to visualise if and how that software be used in a decades time so you can’t really blame the developer of the day if the software is still being used way past its use by date. Businesses need to realise when something has organically grown too far and is starting to get unwieldy to maintain. Rather than constantly developing around it and extending it because that is by far and away cheaper to ship something; tackle the problem earlier rather later as otherwise it’ll just become more and more expensive and maintaining a legacy codebase often holds you back in the marketplace and allows competitors to ship faster and better features than you.

I know that there is the age old adage of "if it isn't broke, don't fix it", but there comes a point where every piece of software has had its day and needs to be retired. The hard bit is knowing when that day actually comes sooner rather than later.

Enjoy!