I was reading a column by Nassim Nicholas Taleb in the Financial Times yesterday, where he lists “ten principles for a Black Swan-proof world”. You can read the whole piece here, or download the pdf from Taleb’s own site.
I couldn’t help noticing how striking the relationship was, between what he was putting forward for financial markets, and what we consider generally to be the principles of opensource and of good software development. So I decided to list each of his principles below, with brief comments in italics seeking to explain the same thing in a software context.
- What is fragile should break early while it is still small. Make sure you test early, test often, test small.
- No socialisation of losses and privatisation of gains. Opensource is pretty much predicated on this: “losses” are borne by individual contributors, “gains” are shared by all participants
- People who were driving a school bus blindfolded (and crashed it) should never be given a new bus. Opensource communities make use of tools like commit logs for this very purpose, looking at the prior contributions made by a participant before letting the changes in
- Do not let someone making an “incentive bonus” manage a nuclear power plant — or your financial risks. We’ve all seen what happens when incentives for technology staff are not aligned properly with business objectives. This is why the most important job of a CIO is “dial-tone”, reliable secure operations at an affordable price
- Counterbalance complexity with simplicity. Build software on a “high cohesion, loose coupling” basis
- Do not give children sticks of dynamite, even if they come with a warning. Make sure that the people who make software decisions actually have software experience
- Only Ponzi schemes should depend on confidence. Governments should never need to “restore confidence”. How many Linux ads did you see when Linux came out?
- Do not give an addict more drugs if he has withdrawal pains. Don’t cure proprietary-software addictions by giving people more proprietary software
- Citizens should not depend on financial assets or fallible “expert advice” for their retirement. Rely on something real. Code. Code is King. Not slideware.
- Make an omelette with the broken eggs. Again an opensource principle. Cannibalise. Reuse.
So what would happen if financial markets get run on opensource principles? Complete transparency. Open inspection. Visible track records. Compartmentalisation of losses, sharing of gains. Moderation not regulation. And yes, the capacity to “fork”.
[Update, with Tongue Firmly in Cheek: If the banking system needs to learn from the software industry, is the opposite true as well? Are we approaching a time when large software firms will need bailing out? http://www.infoworld.com/d/adventures-in-it/microsoft-asks-feds-bailout-720 ]
Great thinking! And don’t forget: some software development projects are too big to fail as well.
Steven
Exactly. There is much in common between large bank bailouts and large project bailouts. What I am particularly interested in is the way that early warning signals are discounted or even completely suppressed.
Ever since I really started to understand and appreciate the complexity of OO designs like abstractions and polymorphism I felt that finance instruments are very similar. This feeling got even stronger since 2007 when the crisis started. Particularly, the CDO is an interface with many implementations. The implementations hide the state (the specific mortgages or other kinds of debt it contains). These debts all have specific behavior and states themselves and so on. There are even OO design patterns at work like Strategy, Adaptor, Observer, … .
It’s not just that these instruments would be implemented like this in a OO financial application, these instruments are actually working according to OO principles.
Steven
As my old man used to say – “if you’re going to fork, fork right”
This is right on. Art Brock makes the same point you are making in his response to Umair Haque’s post on Igniting Finance 2.0 (see the comments of: http://blogs.harvardbusiness.org/haque/2009/04/igniting_finance_20.html ).
The central infrastructure of the economy, money itself, can and must be open-sourced.
@stevendejiver i tried some time ago to think of financial instruments as having APIs. then I lost myself in the world of microformats versus RDF and haven’t wandered back yet.
@davidrendall thanks for the feedback. sometimes when you look at the decision process for very large software projects, the words “criminal negligence” come to mind.
@michaellinton your father sounds like someone I would get along with :-)
@ericharris-braun thanks for the tip-off on the brock comment. I read Umair regularly, just hadn’t caught up. Now you’ve given me an incentive to push his piece up the priority list. A personal Digg as it were.
Refining #4 further. Don’t pay a tester by the number of bugs found. Moral Hazard applies to SW development too.
Absolutely, couldn’t agree more Todd. Thanks
JP: “Complete transparency. Open inspection. Visible track records. Compartmentalisation of losses, sharing of gains. Moderation not regulation.”
At least the future will be better if we learn the right lessons despite all the recent pain.
Eric: “The central infrastructure of the economy, money itself, can and must be open-sourced.”
We communicate with money like we communicate with, well, communication tools.
The G20 looked in the right direction, but not far enough.
Not sure about #7 in the context of open source software.
We consider open source software to be secure and of good quality because of the scrutiny it receives from a thousand pairs of eyes. This makes it statistically unlikely for a bug or security issue to survive for a long time.
But Taleb warned us against confusing “unlikely” with “impossible”. If he is right, maybe our confidence in open source software is ultimately misplaced? Is there a black swan hidden in the linux kernel?
What open source gives us is the opportunity to independently assess the quality of the software, but I’m not sure how well this is done. There are code quality metrics we can apply to the source code but they do not give us assured validation of its function.
With open source software I think we are depending too much on confidence or trust and not enough on rigorous, engineering-led scrutiny.
@dominic the question that comes up when I read that is “just how much do I trust rigorous engineering-led scrutiny?”. The financial equivalents of this “rigour” are Basle II and Sarbanes-Oxley, two sets of regulation that created, exacerbated and finally guaranteed the crisis.
I am sympathetic to what you say, but fear that far too many people put far too much trust in perceived rigour. If I had a penny for every bank that relied on Excel and Powerpoint…. rigour indeed.
I’m not suggesting we regulate open source at all. I’m just suggesting we can get better at evaluating its quality – better than simply relying on crude statistics. I should say IANACS (I am not a computer scientist) at this point…
One of the contributing factors to the financial crisis is everybody using the same models, and using them outwith the scope of their original assumptions. See here for example: http://blogs.reuters.com/felix-salmon/2009/04/14/can-you-stop-banks-acting-like-lemmings/
I’m just making the small point that the same could be said for some widely-used open source software. I still think it’s better than proprietary software for commodity functions, but lets not let our guard down here.