I’m not one who believes in fortune tellers or those who claim to be able to predict the future. Heck, I don’t even read my horoscope and cringe whenever someone attempts to force it upon me. Only when my wife has attempted to read me my horoscope have I offered even as much as a polite “hmm.” Nevertheless there are many out there who swear by those who claim to be able to predict the future, especially in the financial industry.
And while there were those who predicted a rocky road for Facebook’s IPO, it is doubtful that anybody could have foreseen NASDAQ’s technical melt down that surrounded the Facebook IPO. While the stock price predictions for Facebook may be coming true, surely the technical issues that NASDAQ experienced on Facebook’s IPO day could not have been predicted…or could they?
Not in the Cards
As Scott Sellers points out over on Computerworld, it seemed like NASDAQ understood the kind of volume it would be facing and had taken the necessary precautions. He notes, “Exchange officials claimed that they had tested for all circumstances and for thousands of hours. I believe them.”
I believe them, too, but like we’ve said here many times before, and it’s a point to which Sellers alludes in his post, testing isn’t enough. As Sellers puts it, there needs to be “a resilient underlying infrastructure.” Functionality does not always mean structural quality, yet functionality is all that is needed to ensure that applications pass muster when tested. The functionality issues that might be found in an application are merely the tip of the proverbial iceberg that can potentially sink an application after it sails.
This is what, in all likelihood, happened to the NASDAQ on Facebook IPO day and will probably happen again. Why? Because application failures have happened before on numerous occasions and yet NASDAQ did not take heed from those who had gone (down) before them. Last year alone the London Stock Exchange, Euronext, Borsa Italiana (bought by the LSE in 2007) and the Australian Stock Exchange all suffered outages due to technical flaws.
Obviously there’s a lot more to keeping an exchange running than the functional testing can detect and on this point Sellers adeptly points to the CRASH study on application software health released in December. He notes that:
Exchanges are complex, high-performance systems that can be difficult to build, upgrade and debug. According to CAST Software, “an average mission critical application has just under 400,000 lines of code, 5,000 components, 1000 database tables and just under 1000 stored procedures.”
He later adds that, “Having a robust – and well-reviewed architecture nearly always results in a clear competitive advantage.”
Applying the Crystal Ball
Truth is, software failures like the ones experienced by NASDAQ and the other exchanges have become all too commonplace in all industries. Unless it affects a company’s finances directly – as the NASDAQ failure may have done by holding up trading of the Facebook IPO – we treat news of software failures as though they were inevitable and almost expected. In NASDAQ’s case, however, there are now calls for investigations and answers about what happened.
In my book, that’s a good thing. After all, when exactly did we decide that software failure was an unavoidable part of business and an acceptable excuse to leave us hanging and waiting?
NASDAQ, the London Stock Exchange, Euronext…in fact, all exchanges and financial companies need to do a better job of assessing the structural quality of software before it is deployed rather than merely depending on functional or load testing after it is deployment ready. There’s no crystal ball needed here, just automated analysis and measurement, which is now readily available in the marketplace on a SaaS basis. Not doing structural analysis throughout the build is like waiting for an application to fall on its face and fall it will…faster than the share price of Facebook stock.