Sunday 26 May 2013

Agile is Antifragile

Earlier this year I read the excellent book Antifragile by Nassim Nicholas Taleb. He's a bit full-of-himself and has a somewhat quirky writing style, but the ideas in the book are so good that this is easy to forgive. (And in fact, when I had finished the book, I turned around and read it through again, which I never do, so that must say something about the content.)

I've been thinking about the connection between Taleb's ideas and software development for some time — something like five years in the case of my recent essay Bugs with Long Tails — but his previous books don't make it quite so clear how to put into practice the maxim that one should "invest in preparedness, not prediction". In the face of uncertainty, what exactly does it mean to be well prepared?

Taleb has invented the new term "antifragile" as a label for those things which are not merely robust to uncertainty, but actually relish it and benefit from the uncertainty. For example, a tourist who follows a schedule is fragile, because if the bus doesn't arrive it's a disaster. By contrast a "flâneur" who makes no decisions ahead of time doesn't care. If the bus doesn't arrive, it's an opportunity to see things and do things that would never have been on any schedule. Better than robust, they are antifragile: when the unexpected happens, it's an advantage.

Antifragile cherishes "optionality": the ability to do something if it benefits you without the obligation to do it when it doesn't benefit you. You don't need to predict what will happen in the future, provided that you have placed your bets so that you incur a small fixed loss but in return you have the chance to make a large gain. (And because you have an option, not an obligation, if it goes wrong you get to walk away. You never suffer a large loss.) When losses are certain but small and gains uncertain but large, a trial-and-error approach will in the long term bring more than survival: it will bring success.

The problem with this approach is that it takes a kind of moral courage. People hunger for apparent predictability, for a reassuring chain of small gains even at the risk of a huge loss that wipes them out. Day-to-day it's harder to endure the drip-drip of the small losses incurred by the antifragile approach, even when you consciously recognise the long-term benefits. (See Thinking, Fast and Slow by Daniel Kahneman for an explanation of this curious effect.)

In business, the people responsible for each part of a firm will tend to "play it safe": they will try to ensure that they usually do make a small gain, even if they run the risk of a large loss. But from the point of view of the whole business this is a poor choice: it would be much better if the people in charge of each part accepted small losses, provided that in return they had a fair chance of a large gain and no chance of a large loss. They usually don't make this choice, because they don't want to be blamed for the small failure if their bet doesn't pay off. Since they avoid blame, they get to keep their jobs for now, but maybe not for long, because the business as a whole becomes fragile.

A business which is fragile has no choice but to try to predict the future. But in many cases, predicting the future or even just estimating the probability of future events is much harder than most people think. And as I have argued in Bugs with Long Tails, there is evidence that software development is one of those cases where prediction is too hard. We can't do it. And if we can't do it, we shouldn't try. We should "invest in preparedness, not prediction". We should be antifragile. What does that mean in software? It looks a lot like what people usually call "agile".

I'll give just a few examples here, because I'm sure you can fill in more for yourself:
  • Don't try to guess what the customer/product-owner wants. Instead of trying to predict what you can't predict, insist that they are always available to say what they want. (Or admit that they don't yet know, in which case you can help them find out.)

  • Big projects are known to have worse cost over-runs than small projects and this is because they rely so much on prediction. So agile development splits big projects into short iterations/sprints a few weeks in length, each of which delivers some finished product, worthwhile on its own. A few of these iterations may fail, but that's fine. Learn your lesson and move on: small, isolated losses; large overall gains. To paraphrase Kent Beck: "The purpose of planning is not to predict the future, but to know that you are working on the most important thing right now."

  • In Extreme Programming there are the principles "You Aren't Going To Need It" and "Do The Simplest Thing That Could Possibly Work". The least productive development work is building code that is never needed. But we don't have to predict what code we need right now, because we already know. For code that we don't need right now, we have to predict what people in the future will need our code to do, how efficient it must be in time and space, and lots of other details that we currently know nothing about. Very often we are wrong in these predictions. Better to make a bet that we will never need that code and accept the small loss of changing the code later if it proves inadequate. The big payoff if we win the bet is less code and less overall work.

Another relevant example of antifragilility can be found in the architectural work of Christopher Alexander. (Though it's curious that Taleb doesn't mention Alexander, especially since he does mention How Buildings Learn by Stewart Brand.) It's well known that in the 1990s, the same people in the object-oriented programming community who came up with the idea of agile development also worked on "patterns", inspired by Alexander's books The Timeless Way of Building and A Pattern Language: Towns, Buildings, Construction.

Less well-known in the software development world is that Alexander became dissatisfied with patterns because they did not reliably generate the kind of "living structure" of buildings that he describes in The Timeless Way of Building: buildings that have the "Quality Without A Name". This was a problem, but a problem with a happy ending, because he describes the solution in his massive follow-on work The Nature of Order. (Over 2000 pages in four volumes: Book 1, Book 2, Book 3, Book 4.)

Alexander has even more to say in this magnum-opus than Taleb in Antifragile, but the key point for us here is the idea of a "generative sequence". The patterns are useful, but to do their work properly they must be used in a disciplined way, in a specific generative sequence where nothing has to be predicted ahead of time, but decisions only made based on what is visible right now, in the situation at hand. For example, Alexander gives a 24-step generative sequence for building a Japanese tea house (vol. 2, p303-304) starting with a secluded garden. Within this sequence, step 12 is to lay out a particular path, step 13 to choose a stone water basin and place it on this path, and so on. The trick is that having made a decision at one step it is never necessary to go back and revisit an earlier decision, nor is it necessary to consider a later decision ahead of time. There is no planning.

It's surprising that this approach works at all. Why should it be possible to find generative sequences which allow things to be designed step by step and never go back to revisit an earlier decision? And yet it does seem to be possible to find these sequences, and they do seem to be able construct things which have the "Quality Without A Name". Expert knowledge therefore encompasses not just the patterns, but the generative sequences that make them work and the principles used to discover generative sequences. (And most of The Nature of Order is about these principles.) As Alexander notes:

"The significance of generated structure lies in the concept of mistakes. Fabricated plans always have mistakes — not just a few mistakes, but tens of thousands, even millions of mistakes. It is the mistake-ridden character of the plans which marks them as fabricated — and that comes from the way they are actually generated, or made, in time. Generated plans have few mistakes." (vol. 2, p186)

Generated structures don't avoid mistakes — their construction involves many mistakes. But these are cheap mistakes, easy to notice and quick to correct. Always corrected before going on to the next step. Planned structures probably involve the same number of mistakes, but a plan doesn't give you any feedback, so every mistake persists and is built into real-life.

We borrowed the idea of patterns from Alexander. We could frame agile development as another borrowing, an application of Alexander's idea of generated structure in the world of software development. We still seem quite a long way from having reliable generative sequences in software, apart from the tacit craft-knowledge embodied in individuals and small groups, but maybe in the future we can do better. Maybe we could see the agile "movement" as a search for such generative sequences. However, I think an even better framing would be to see both agile development and generative sequences as instances of antifragility. This perspective emphasises what gives them both their power: avoiding plans and prediction when we can't know enough to predict correctly.

(I've noticed that I'm not the only one to have seen a link between Taleb's ideas and agile development: see Agile=Antifragile. If you'd like to see Taleb talking about his ideas, you might like to watch this video filmed at the New York Public Library. You can also find much better account of how Alexander's ideas relate to software in Part One of Patterns of Software by Richard Gabriel.)

Sunday 19 May 2013

Recipe: Lamb kebabs

This is really two recipes: the lamb kebabs themselves and a yoghurt-and-cucumber thing to go with them.


500g Minced lamb
1 Egg
1t Ground coriander
1t Ground cumin
1T Paprika
0.5t Cayenne pepper
0.25t Salt
pinch Ground pepper
(1T = one tablespoon = 15ml; 1t = one teaspoon = 5ml)


Blend all the ingredients except the mince together, then thoroughly mix this into the mince and set aside in the fridge (for at least 2 hours, but all day if possible).

Split the mixture into 6 equal pieces and form each piece into a sausage shape on a kebab skewer. Grill for 10 minutes, then turn over and grill for another 10 minutes. (Of course, in summer you can cook them on the barbecue.)

Yoghurt and Cucumber

This goes very well with these kebabs. It's a bit like tsatsiki.


500g Greek yoghurt
1 Cucumber: peeled, de-seeded and chopped
1T Fresh coriander, chopped finely
1T Fresh mint, chopped finely
1T White wine vinegar
0.25t Salt
pinch Ground pepper
(1T = one tablespoon = 15ml; 1t = one teaspoon = 5ml)


Combine all the ingredients and mix well. Chill in the fridge for a couple of hours. Serve.

Sunday 12 May 2013

A Day at elBulli

I'm looking at my copy of A Day at elBulli, a very thick book by Ferran Adrià which gives a minute-by-minute account of a typical day at the restaurant elBulli. I don't suppose that I get this book down from the shelf more than once a year, but I think more than any other book it was this one which convinced me that software development has a lot more in common with cooking than with architecture.

elBulli was a rather unusual restaurant. (It closed in 2011.) It opened for only 160 days a year, summer through to winter, serving one sitting of 50 guests each day. The kitchen staff of about 40 prepared a fixed "tasting menu" of around 30 miniature dishes for each guest, served by a front-of-house staff of about 25. (Although tiny, each dish generally took more effort to prepare than most main courses in most restaurants. Only 50 customers a day sounds easy. Think of 1500 complex main-courses a day and you have a better idea how much effort was involved.)

They served around 8000 guests a year, but they got many, many more requests for reservations. Around 2 million. And yet they only charged around €200 per head. Clearly they could have charged much more; clearly the main purpose was not to make money, but rather to research new recipes and techniques. It was a research restaurant. Who would have thought such a thing was possible?

When I first read the minute-by-minute descriptions in the book, I was reminded somehow of happy experiences working in an Extreme Programming development team. Everyone doing hands-on work to some extent, everyone conscious of working together to make something, always working with one eye on the clock. I was also struck by the discipline, similar to XP:

  • Simple, direct organisation, with stand-up meetings at the start and end of the day.

  • Clear up as you go. Even though it's late and everyone is tired, everything is left neat and tidy at the end of the day, ready for a fresh start tomorrow.

  • Process, timing and organisation are everything. But the physical artifacts used to track progress are very simple: order-sheets, plans for mise-en-place, shopping lists.

What lessons can software developers learn by looking at a restaurant like this? First maybe that they both have customers, and the customer's experience in both cases has very little to do with the essential nature of producing that experience. What does the customer see? Only the front-of-house.

There are front-of-house staff and kitchen staff. Though the kitchen is the heart (without the kitchen there is nothing) most guests don't see it, and know almost nothing about the production of their food. This certainly has echoes in software development. The customer is oblivious to what goes on behind the scenes, and the effort to make it work. But strangely, in software the front-of-house staff often set the terms for the kitchen staff despite having little hands-on knowledge about the production processes.

Another lesson is that process is key. It's all about process. But not the kind of stupid "big process" checklist in some binder somewhere that everyone ignores. No, the key is the precise minute-by-minute, hour-by-hour knowledge of how to actually do things the best way. Sometimes this is written down, but often not.

At elBulli, most kitchen staff did "process execution". A few, particularly Ferran Adrià himself, focused on process creation, figuring out what dishes to make and how best to make them. Every day inventing and perfecting processes, refining recipes and the techniques for making existing dishes. Experimenting with new ones. This is an obsession with process: hundreds of trials, failures, tweaks and variations to perfect the process to make each dish. And from the point of view of the customer, this long effort and many failures was completely hidden, though the final dishes could not be served without it.

The meta-idea here is to have complete control of process, a process even for creating processes. Now with software development, for all our claimed enthusiasm for process, are we really in the same league as these guys? I don't think so. We just don't see this kind of perfectionism very often, and when we do see it (for example in Extreme Programming) it is thought of as something odd and bizarre. Not like elBulli, a magnificent example of the art, which others admire, respect, and aspire to emulate.

Have a look at A Day at elBulli. It's worth considering: what if we applied that kind of attitude to software?

Sunday 5 May 2013

Recipe: Red-cooked Pork

This recipe was originally based on one from Cheap Chow: Chinese Cooking on Next to Nothing by Kenneth Lo, but it's diverged a little bit since then. The result is quite similar and as Kenneth Lo says: "The combination of meat, fat, skin and gravy is probably about the most savoury and appetizing thing in the whole realm of Chinese culinary creation".


1.5kg Belly pork slices (each about 1cm thick)
6T Sunflower oil
5t Light soy sauce
180ml Medium-dry sherry
180ml Water
1t Five-spice powder
2t Sugar
2 Star anise
(1T = one tablespoon = 15ml; 1t = one teaspoon = 5ml)


Preheat oven to 150°C (= gas mark 2 = 300°F).

Heat the oil in a wok or frying pan, and brown the belly pork slices in batches, a few at a time. Place them in a large casserole.

Mix all the other ingredients and pour this sauce into the casserole too. Arrange the belly pork slices so that they are packed closely together. Cook in the oven for about 4 hours, turning the pieces over every hour, so that they cook evenly.


I think everyone has a slightly different recipe for red-cooked pork. The Kenneth Lo recipe in Cheap Chow (p48) takes the meat in a single piece, rather than sliced, and cooks it for 1 hour with only a quarter of the sauce in the above recipe, then another 1 hour 30 minutes after adding another quarter of the sauce (and no five-spice powder). Fucia Dunlop in Revolutionary Chinese Cookbook (p78) uses fresh ginger, star anise, chilli and cassia bark for flavour, and simmers the dish in a wok for 50 minutes rather than in the oven. (Which leaves it a bit chewy for my taste.)