Facebook, the galactically popular social networking site that for so long has weathered friction regarding weaknesses in its software – particularly around security and privacy issues – may have seen its own IPO effort submarined by a software glitch in the NASDAQ stock exchange.
In reporting on NASDAQ's response to the technical difficulties it encountered on Facebook's IPO day, Bloomberg’s Nina Mehta writes:
Computer systems used to establish the opening price were overwhelmed by order cancellations and updates during the "biggest IPO cross in the history of mankind," Nasdaq Chief Executive Officer Robert Greifeld, 54, said yesterday in a conference call with reporters. Nasdaq’s systems fell into a ‘loop’ that kept the second-largest U.S. stock venue operator from opening the shares on time following the $16 billion deal.
According to Mehta, the reason Greifeld gave for the issues with the IPO was “poor design in the software it uses for driving auctions in initial public offerings.”
One would think that if any exchange out there were to be free of poorly designed software it would be the Tech-heavy NASDAQ exchange. Apparently offering the top Tech companies in the industry, though, does not necessarily mean you run the best software the Tech industry has to offer.
Profile of a Failure
Truth is, software failures like the one experienced by NASDAQ have become quite commonplace lately; so much so that they’re practically met with a shoulder shrug and an “oh well.” We treat news of software failures as though they were inevitable and almost expected. Only when it affects finance – particularly the financial status of a marquis brand name like Facebook – do we step back and even offer so much as a “tsk, tsk, tsk” for the failure.
But why? When exactly did we decide that software failure was an unavoidable part of business, an acceptable excuse for possibly undermining the value of a highly touted IPO?
Facebook reached a high of $45 per share before it dropped back below its initial offering price of $38 per share. Whether the glitches at NASDAQ caused the per performance or whether you agree with Henry Blodget at Business Insider that they were just a convenient excuse for a poor showing, there is still no excuse for application software failure, especially since we know what causes it:
- Business Blindspot: Regardless of the industry, most developers are not experts in their particular domain when they begin working for a company. It takes time to learn about the business, but most of the learning, unfortunately, comes only by correcting mistakes after the software has malfunctioned.
- Inexperience with Technology: Mission critical business applications are a complex array of multiple computer languages and software platforms. Rather than being built on a single platform or in a single language, they tend to be mash ups of platforms, interfaces, business logic and data management that interact through middleware with enterprise resource systems and legacy applications. Additionally, in the case of some long-standing systems, developers often find themselves programming on top of archaic languages. It is rare to find a developer who knows “everything” when it comes to programming languages and those who don’t may make assumptions that result in software errors that lead to system outages, data corruption and security breaches.
- Speed Kills: The pace of business over the past decade has increased exponentially. Things move so fast that software is practically obsolete by the time it’s installed. The break-neck speeds at which developers are asked to ply their craft often means software quality becomes a sacrificial lamb.
- Old Code Complexities: A significant majority of software development builds upon existing code. Studies show that developers spend half their time or more trying to figure out what the “old code” did and how it can be modified for use in the current project. The more complex the code, the more time spent trying to unravel it…or not. In the interest of time (see “Speed Kills” above) complexity can also lead to “work arounds” leaving a high potential for mistakes.
- Buyer Beware: Mergers and acquisitions are a fact of life in today’s business climate and most large applications from large “acquirers” are built using code from acquired companies. Unfortunately, the acquiring organization can’t control the quality of the software they are receiving and poor structural quality is not immediately visible to them.
A Comment on Facebook’s Status
NASDAQ may need to pay back $13 million to investors who should have received transaction executions but did not because of its software failures. Meanwhile, brokers around the world may lose $100 million repaying investors for mishandled orders. A quick, pre-deployment application of automated analysis and measurement to diagnose the structural quality and health issues within the application software used by NASDAQ or any company would have been a much better investment of time and money.
I guess this is one more reason to lobby for a “DISLIKE” button.
Erik Oltmans, an Associate Partner from EY, Netherlands, spoke at the Software Intelligence Forum on how the consulting behemoth uses Software Intelligence in its Transaction Advisory services.
Erik describes the changing landscape of M & A. Besides the financial and commercial aspects, PE firms now equally value technical assessments, especially for targets with significant software assets. He goes on to detail how CAST Highlight makes these assessments possible with limited access to the targetâ€™s systems, customized quality metrics, and liability implications of open source components - all three that are critical for an M&A due diligence.