Should the mortage bond meltdown be considered a "black swan" event?

I think there are a couple of ways to look at the question of whether the mortgage meltdown (see a nice discussion here) is a black swan in Taleb's sense.

For investors who bought these bonds because they were rated more highly than they should have been, it may be a black swan. These investors (mainly institutions) relied on rating agencies to tell then how risky the mortgage-backed bonds are. I don't think they can be criticized for that. After all the point of a rating agency is to provide risk ratings. Either one does it oneself or one relies on others. Since one can't do everything oneself (that's the benefit of specialization, etc.) one must rely on others. So for that group of people it was a black swan event in the same way as it would be a black swan event for the US army to stage a coup because it was fed up with how it was being destroyed by our policy in Iraq.

On the other hand, the mis-rating of the bonds was not a black swan event from the perspective of the rating agencies and the banks that sold them. It was an error on the part of the rating agencies and greed on the part of the banks (and also on the part of the rating agencies). That's not a black swan event.

One can claim that it was a complex systems event in that the incentives were wrong — and no one paid attention to the incentive structure. I have no problem with that analysis. That's an example of an unintended consequence of setting up a mechanism (that provides access to resources) that is then used in ways that were not intended. So one can pull in a complex systems analysis through that route.

In a complex systems course I'm developing I talk about this, namely that access to resources is fundamental to almost everything and that systems will often move in directions that are determined by agents finding ways to access resources rather than by other "intended" purposes.

So from this perspective the mortgage meltdown was not a black swan, it was an unintended consequence. I think there is an important distinction between black swans (which are not predictable except, perhaps, if one analyzes the entire universe) and unintended consequences which are in fact predictable (if unintended and undesirable) consequences of systems we design. (Bookstaber talks about this also. In fact, the liquidity problem of selling these bonds in a market that doesn't want them is just the sort of liquidity enhanced problem that Bookstaber talked about.)

In summary, for the institutions that bought the incorrectly but highly rated bonds, it was a black swan because (a) they were not in a position to question the rating agencies and (b) it is a black swan for the rating agencies to be so wrong. For the rating agencies and the banks that sold the bonds it was not a black swan but an unintended but predictable consequence of the structures within which they were operating.

The fact that Goldman Sachs recognized and profited by the possibility of the meltdown is evidence for this analysis. One typically can't bet on a black swan. The odds are too remote. All one can do is attempt to protect oneself from them and position oneself to take advantage of them should they occur. In contrast, one can (as Goldman did) analyze a situation and see in it a structure that others are ignoring and bet on that. That I'd say is a nice way to distinguish between a black swan and an unintended consequence.

This discussion illustrates how something can be a black swan event from one perspective but not from another. Taleb likes giving the example of a farm-raised turkey and the view of life he would develop. Day after day he is fed and taken care of. The more days that go by, the more comfortable he feels that life is good. His confidence grows and grows — until the day before Thanksgiving when a black swan event occurs.

In this case, of course, one could say that the event of being the Thanksgiving dinner was a black swan event because the turkey simply didn't have enough knowledge. But then we never have enough knowledge. There will always be items of information that if they had been considered might have warned us about something that otherwise surprises us.

Multi-processing

The New York Times has an article on multi-core processors. It's focus is primarily on the fact that Microsoft is taking the problem seriously and putting lots of money into it. The problem, if course, is that software developers don't know how to develop software for parallel computation. The article quotes David Patterson of Berkeley as saying

Industry has basically thrown a Hail Mary. The whole industry is betting on parallel computing. They’ve thrown it, but the big problem is catching it.

The "Hail Mary" reference is to the fact that the hardware industry has run into problems that makes it very difficult to make individual chips run faster. The alternative to faster chips is more chips. That also increases the raw computing power. The problem is that we don't know how to use it.

Parallelizing software is very difficult. We don't know how to do it. It's unlikely that we will solve that problem soon. So what's to do? Two things.

• We can and should focus on more loosely coupled processes. Parallelization is the attempt to break a single process down into subprocesses that can perform the same overall computation but with some of them done in parallel. Loose coupling is an attempt to think about computation in terms of multiple computations that interact less often. It's coordinating the interactions that make parallelization so difficult. If there were fewer interactions or if the interactions were less tightly coupled, the result would be easier to produce. Of course that's easier said than done. But agent-based computing has been around for quite a while, and it has produced some useful results.
  
  On the discouraging side is the fact that process algebra has also been around for quite a time and has not produced much in the way of practical results. We just don't know how to coordinate even loosely coupled processes except through very generic mechanisms. The fact that most of what we experience in life consists of loosely coupled processes should be encouraging. But we have a long way to go before we understand how it works.


• The second approach is to work on developing systems that work at many levels of processing simultaneously. Apparently our brains do that. At the same time as we are doing something we are aware of the fact that we are doing it, and we can regulate how we do it. Aspect-Oriented Programming (AOP) is a move in the right direction. It is an attempt to develop programming languages that allow the programmer to write software that both operates at the process level while at the same time operates at a meta-level that observes the operational level. AOP as currently structured attempts to map all of these processes onto a single process programming language. That, of course, is not only not necessary, it's the wrong way to proceed. In the future we will have many processors. We should be working on putting them all to work at different observational levels.