The Efficient Market Hypothesis

Much of finance theory depends on an efficient market, essentially the condition whereby all participants have access to the same information at the same time, more or less. It is the operation of the efficient market that eliminates arbitrage opportunities.

In my youth I had an exceptional finance lecturer, Eve Hicks, her position on the efficient market was that it clearly didn't exist, but in the absence of anything better, it formed a conceptual framework upon which finance theory could be built. I have respected and subscribed to that point of view ever since, even believing that the fall of open outcry and the emergence of the electronic exchange has made the efficient market that little bit more real.

How then, if indeed the efficient market is to even be considered as a valid model, did the sub-prime collapse catch so many 'experienced' traders off guard, the collective genius at Goldman Sachs excluded of course. Surely, with equal access to the same information every risk department of every bank and fund should have been hedging against the CDO's that have ultimately triggered the current volatility.

The answer lies not in flaws of the efficient market hypothesis but in the plain fact that success flatters to deceive. For many, the CDO proved to be a license to print money and while the good times are that good, one tends to overlook glaring compromises or risk factors that would otherwise be great cause for concern.

And so it is with technology, as a product becomes a run away success, the impetus is to build on that success and the suggestion that the foundation may need shoring up is eschewed by management and marketing in favour of 'more things that made us successful'.

As with CDO's, when reality hits and the wheels come off, do not expect management and marketing to offer a sincere 'my bad', they were simply doing their job. As software engineers, the code base is our efficient market, when we see gathering problems, it is our responsibility to begin hedging against them, re-factoring is our derivative.

Re-factoring needs to become an every day part of your role as a software engineer, you will never be given large blocks of time specifically for re-factoring, it is a day to day responsibility; ignore it at your peril, unless of course there is someone else you can blame.

POUNDY!!!!!!!!!