I’ve been promising since I started this blog to write about Nassim Nicholas Taleb’s book, The Black Swan. Today is the day I finally make good on that promise…
Imagine for a second, that you know how the world works, it should be quite easy. Imagine further that you have a grasp on the causality of this world, certain actions lead to certain consequences. Imagine even further that you can have a rough idea of how things are going to turn out based on what you can see and experience.
All of this should be pretty straighforward to most of us, after all that’s what we do every day. We believe we know how things work, and how they will work tomorrow. Even the distant future of next year we have a pretty good grasp of how things are going to be, because we’re not stupid, and we can see what’s going on around us.
Now imagine you’re the CEO of an airline just before the icelandic volcano. Or a financial banker before the banking crash (the latest one). Or an Executive of Altavista before Google launched.
Seems a little different, doesn’t it? That’s the key idea in NNT’s book, the outliers have such a great effect that simply dismissing them as outliers is not good enough anymore.
The Black Swan, at it’s heart, is a study on probability, dressed up in good research and narrative, both of which are pointed out by the author to cause particular weakness in most of us. The question it raises is centered around how we think about probability, how our prediction models and our expectations are structured.
Fundamentally NNT advocates that we need to move away from the conceptual model of probability we have in our heads, that outliers are rare and don’t affect the main body of results, and move towards emiprically gained evidence, without assumption. And that this evidence, resembles most Madelbrotian, of fractal fame, probability, that is, that the more you zoom in, the more it looks the same.
I’ve been thinking a lot about this book and how I can apply it to my professional life. Agile software development is fundamentally a technique that allows development teams to reduce risk of the unknown.
In the various flavours you get agile in this is pretty apparent; Scrum: sprints are effective little projects with limited scope. with the same risks and pitfalls as bigger projects, but at least you’re dealing with them immediately and can mitigate the risk next time. XP exposes code to review as soon as it’s written. Other agile methodologies, repeat this pattern in various forms, always mirroring larger projects but at a much smaller scale.
The same goes for actually building teams, Fred Wilson put up a post recently about the balance between product and engineering as a startup scales. Essentially to maintain the true essence of what made the startup great, you’ve got to keep the same balance that you had in the beginning, which normally means you’ve got to let go of one or both areas.
The key thing is that as soon as we treat something as being a smaller representation we also get better at predicting the larger representation even as we get worse at predicting the smaller ones. Perhaps that was a little bit of a stretch, the idea is that because we can fit a project on a gant chart, we lie to ourselves that we know how it’s going to go. Anyone that’s ever run a project knows that this is rubbish. Breaking the project up into smaller chunks doesn’t mean we get better at predicting the success of those smaller chunks.
Using Scrum as an example, i’ve seen teams implementing it very well that fail 75% of the time on delivering on their sprints. That is, they’re late with one or two items, or one or two aren’t done two spec. The key thing about scrum is that you take this aggregating cumulative error into account when the project as a whole is being discussed. Because we screwed up 75% of the time, our overall estimate is only 75% accurate. and the closer you get to the end, the less screwups you have ahead of you, therefore the more accurate you get.
Detractors of Agile methodologies have long used this as an example of how bad agile is, after all they’re 75% wrong off the bat. What the detractors don’t tell you is the failure rate of projects without using agile. it’s about 75%. The smaller units at least allow you to be wrong earlier, and therefore either take corrective action or give up altogether.
We fundamentally assume that we understand how the world works, and that it works the way it does because of some underlying reason that we think we’re just on the edge of grasping. Which just about sums up how some project managers feel about development projects… “It should have worked, we did everything right right up until it all fell to pieces.”
