Sunday 27 October 2013

Recipe: Chicken Español

This recipe was reverse-engineered from a Tesco ready-meal.


3Chicken breasts
2T Olive oil
2t Paprika
9 slices Thinly sliced choritzo
120g Cheddar cheese, grated
420g Cream cheese
Ground pepper
For the sauce:
1 Onion, finely chopped
2 Cloves garlic, crushed
3T Olive oil
1 Tin of chopped tomatoes (440g)
pinch Sage, dried
pinch Thyme, dried
pinch Oregano, dried
250ml Red wine
Ground pepper
(1T = one tablespoon = 15ml; 1t = one teaspoon = 5ml)


On the day before you want to cook this, first make a sideways slit in each chicken breast, making a kind of pocket. Then put the chicken breasts in a plastic bag with the olive oil, paprika and a few grinds of salt and pepper. Squidge this around until the breasts are all covered with this marinade then tie the bag and leave it in the fridge overnight.

To make the sauce, fry the onion and garlic in olive oil over a medium heat until the onion is turning brown. Add the chopped tomato, sage, thyme and oregano. Then add the red wine. Add salt and pepper to taste. Cook for around 30 minutes until thickened. (Reduce heat as necessary. Blend with a hand-blender if you want it to be smoother.)

While that is going on, assemble the chicken with its other ingredients. Each chicken breast cooks in the oven in its own container, which should be about twice as big as the breast itself. (Replicating in some sense the original ready-meal experience.) Assemble each container as follows: first put 100g cream cheese in the base. On top of that, sprinkle 20g of grated cheddar and a couple of grinds of salt and pepper. Now take a breast and into the "pocket", place 40g cream cheese mixed with 20g grated cheddar. Place the breast in the container and cover it with 3 slices of choritzo. Place the containers in an oven pre-heated to to 200°C (= gas mark 6 = 400°F) and cook for around 30 minutes.

To serve, lift out each breast onto a plate, stir around the creamy sauce in its container and pour this sauce around the breast. Beside this, place a similar quantity of the tomato-and-wine sauce. (For a vegetable, steamed spinach works very well and makes a nice colour combination.)


You will find that you have too much of the tomato-and-wine sauce: the above quantity would work for twice as much chicken. However, it's less fiddly to make a bigger batch. For convenience you can make the sauce well ahead of time and even freeze it and re-heat it. Although it's probably not necessary to give each breast its own little container, I think it probably is necessary to confine the area over which the creamy sauce can spread, so that it doesn't burn and the breasts don't dry out.

Sunday 20 October 2013

Democratic Development

(This post is another follow-up to Agile is Antifragile.)

I recently finished The Democracy Project by David Graeber. It's an excellent book, in part a personal history of the Occupy Wall Street movement, and in part an explanation of how to organise groups and solve problems using the consensus processes of "direct democracy". To my surprise, I realised that Graeber's insights can also be applied to software development. I think these insights explain not only what Agile development is really trying to do, but also reveal a cornucopia of organisational techniques that we can reuse to improve our practice of Agile development.

In Agile development, the team is supposed to organise itself — "horizonally" as Graeber would say — rather than being directed "vertically" by some manager. But exactly how? Practically every Agile process mandates short daily meetings, but practically no Agile process suggests in detail how those meetings should be run, or exactly how they lead to the team organising itself. What's really going on here? And why is "horizontal" better than "vertical"? As Graeber explains, what should be going on is decision making by consensus:

This is how consensus is supposed to work: the group agrees, first, to some common purpose. This allows the group to look at decision making as a matter of solving common problems. Seen this way, a diversity of perspectives, even a radical diversity of perspectives, while it might cause difficulties, can also be an enormous resource. After all, what sort of team is more likely to come up with a creative solution to a problem: a group of people who all see matters somewhat differently, or a group of people who all see things exactly the same? (Graeber, p203)

The reason for adopting consensus in a group is that "horizontal" decision making produces better decisions. And the key thing to notice is that the point of every meeting is to decide what to do next, in order to further the common purpose of the group. (There can still be some disagreement. In particular, there is no need to agree on "why". Agreement on "what" is sufficient.) Graeber goes on to explain:

The essence of consensus process is just that everyone should be able to weigh in equally on a decision, and no one should be bound by a decision they detest. In practice this might be said to boil down to four principles:
  • Everyone who feels they have something relevant to say about a proposal ought to have their perspectives carefully considered.
  • Everyone who has strong concerns or objections should have those concerns or objections taken into account and, if possible, addressed in the final form of the proposal.
  • Anyone who feels a proposal violates the fundamental principle shared by the group should have the opportunity to veto ("block") that proposal.
  • No one should be forced to go along with a decision to which they did not assent.
Over the years, different groups or individuals have developed systems of formal consensus process to ensure these ends. ... In fact there's an endless variety of ways one might go about making decisions in the spirit of those four principles. (p211)

You might question whether these principles of consensus are really what Agile development is about. You might say, yes, these principles are going to lead to better decisions. But the developers are, at the end of the day, paid staff. If someone in authority decides to impose a decision, the staff will have to go along with it even if they do detest it. Maybe so. But I think this actually means that consensus is an excellent touchstone for whether or not you are really doing Agile development. I think that at the point when someone outside the team does impose a decision, at that moment you know that you are no longer doing Agile development.

Graeber goes on to explain a particular widely-used consensus process for moderately sized groups which grew out of several different traditions, including Quakerism and radical feminism. I won't go through it here (it's outlined on p214-215) and as Graeber says, maybe in a small group that kind of formality is not needed, if everyone understands the consensus principles. But it does help, I think, to have concrete processes to consider and use in larger groups. Everything invented in the world of Agile development seems to be foreshadowed in the world of "direct democracy". For example, a "Scrum-of-Scrums" meeting is almost exactly the same as a "spokescouncil". I think we can learn a lot from these people.

(If you want to see what some of these formal processes look like in more detail, you can find a good overview in The Five Fold Path of Productive Meetings by Starhawk.)

Sunday 13 October 2013

Recipe: Spare Ribs

This recipe is a bit long-winded, but the results are excellent.


1.5kgSpare ribs
60g lard
1t Fennel, ground
1t Sichuan pepper, ground
1 Cao guo (or "false cardamom")
1 Piece of cassia bark (finger-sized)
2 Star anise
1 Onion, finely chopped
3 Cloves garlic, finely chopped
2 Slices of root ginger, finely chopped
500ml Water
500ml Chicken stock
2t Salt
(1T = one tablespoon = 15ml; 1t = one teaspoon = 5ml)


Bring a large pan of water to the boil. (I use a 10 litre stock-pot.) Add the ribs, bring the water back to the boil and leave the ribs to cook for a further 5 minutes. Skim off the scum which rises to the surface. Lift out the ribs and transfer them to a slow-cooker.

Heat the lard in a frying pan and when hot add the fennel, Sichuan pepper, cao guo, cassia bark and star anise. After 1 minute add the onion and cook this until it is brown (around 5 or 10 minutes). Add the garlic and ginger when the onion starts to turn brown: they don't want to cook for so long, only a minute or two. When it's ready, tip the contents of the frying pan into the slow-cooker with the ribs.

Use the 500ml of water to deglaze the frying pan, and add this to the slow-cooker too. Also add the chicken stock and salt to the slow-cooker.

Cook at a gentle heat for 3 hours, moving the ribs around every hour or so.

Lift the ribs out onto a roasting tray and strain the liquid from the slow-cooker through a sieve into a saucepan. Skim off the fat into a container and keep it to hand. Reduce the sauce on a high heat.

Place the roasting tray containing the ribs in an oven pre-heated to to 200°C (= gas mark 6 = 400°F). After 15 minutes, turn the ribs and baste them with some of the skimmed fat. Return to the oven for a further 10 minutes.


This recipe evolved from a combination of other recipes, mostly those of Kenneth Lo and Ken Hom. It's not clear to me which of the fiddly details is really necessary to produce an excellent result, and I haven't gone to the trouble of scientifically experimenting to find out. I think that frying the spices and then basting the ribs with the oil at the end must make a significant difference, because that should transfer fat-soluble flavours more reliably to the final product.

As an alternative to putting the salt in with the stock-pot ingredients, you can instead grind salt over the ribs when you place them in the roasting tray, and then again on their other side after you turn them over and baste them with fat.

Sunday 6 October 2013

Time, Value and the dark side of Agile

(This post is a follow-up to Agile is Antifragile.)

What is the best way to organise a group of people who are working together to make some software? This must be the central question of software engineering, but we tend to think about it in a very narrow way. It's rather odd that we are happy to talk about processes, from Waterfall to Agile, but we don't like to talk about the kind of practical problems that always arise when people come together to make something for money.

These practical problems are standard fare in business schools and in some mainstream engineering courses, where they are discussed under the label Organisation Theory. This in turn has its roots in ideas of "political economy" that go back over 200 years. Once you understand these ideas, you can see clearly the cause of some tensions that arise in software development. So, let's see if I can introduce you to these ideas — I don't expect in this post to get to the twentieth-century fashions started by Taylor and Mayo, but we should be able to cover enough of the nineteenth century ideas to understand the different feelings people have about Agile and to recognise its dark side.

Where to start? Lisp-hacker Paul Graham, in his essay How to Make Wealth, uses the following example to explain how wealth or "value" can be created by people out of nothing:

"Suppose you own a beat-up old car. Instead of sitting on your butt next summer, you could spend the time restoring your car to pristine condition. In doing so you create wealth. The world is — and you specifically are — one pristine old car the richer. And not just in some metaphorical way. If you sell your car, you'll get more for it. In restoring your old car you have made yourself richer. You haven't made anyone else poorer."

Graham uses this parable to explain where the wealth comes from when people work for themselves in a start-up company: it comes from people spending their time working on something that's useful to themselves and to others. This is scarcely a new thought, and although it would be more traditional to say that "value" comes from "socially necessary labour time", Graham's explanation of wealth is essentially the same as the traditional one.

However, there is a subtlety here which Graham glosses over, a subtlety that the old-time political economists were well aware of: it's the issue of how things change when, rather than working for yourself, you work for someone else. Following the culinary theme of this blog, let's invent our own parable, with people working for someone else in the kitchen of a restaurant.

In our make-believe restaurant there is a proprietor who pays the rent and provides the furniture and most of the kitchen equipment. Every day the proprietor buys the ingredients for the meals and pays the wages of the staff. In return, the staff work a certain number of hours each day, during which they transform those raw ingredients into the meals which customers buy. Value has certainly been created, and in return for this newly created value, the customers leave money after they finish their meals, money which is collected by the proprietor.

The key point here is to notice where the new value comes from: it comes from the staff who spend their time preparing and cooking the food. Not from the proprietor, who merely acts as a facilitator or catalyst by providing the money that makes their work possible. In Graham's car-refurbishment example, imagine that over the summer you keep the stripped-down car in your uncle's garage as you do the work. Does the fact that he is providing the garage mean that he is directly creating value? No. He is facilitating the creation of value, but unless he works on the car with you, that's all he is doing. Without him, you would not be able to create value, but without you, he would just have an empty garage and there would be no newly created value, no new wealth.

Now we come to the central tension between the proprietor and the restaurant staff: how does the newly created value get shared out? Assuming the restaurant makes a profit, then after necessary running expenses are paid, how much of the remaining money goes to the staff as wages and how much to the proprietor? They both have a moral right to that money, since they both have to play their part in order for the new value to be created. There is an unavoidable tension here: they are both in the right.

From the point of view of the proprietor, wanting to keep more of the money for themselves, there is no reason to pay the staff more than the current going-rate. Look around: what are other restaurants paying? You really don't need to pay any more than that. If you do, you are certain to find people knocking on your door asking to work for you, regardless of what fraction of the takings you keep for yourself and what fraction you distribute to your staff as wages. And of course, if you pay less than the going rate, your staff will be tempted away by better offers elsewhere. You won't actually have a restaurant if all your staff leave.

So, the necessary level of wages is determined by the world outside the restaurant, and provided the proprietor pays those wages, they can take whatever money is left for themselves. We would naturally expect the proprietor to try and take more rather than less, and there are essentially two main methods to achieve this: the proprietor can either try to increase the productivity of each member of staff — but still pay the same wages — or they can try to "de-skill" the work, then hire less-skilled employees who can be paid less to produce the same value.

The classic way to achieve the first of these aims is to increase productivity by the "division of labour", described by Adam Smith in the eighteenth century and celebrated today on the back of the British 20 pound note. The idea is that if particular people specialise in particular tasks, then they will perform these tasks quicker than if they continually switch from one thing to another. This is the essence of the twentieth-century factory, with jobs reduced to fitting a particular part or tightening a particular bolt all day. And in the kitchen we do see division of labour to some extent, with specialists in sauces and deserts, for example.

More interestingly, and less often noticed, the division of labour can also achieve the second of the proprietor's aims: it can change the nature of the work, de-skilling it and allowing the proprietor to pay reduced wages, at least to some of the staff. This was well understood by computing hero Charles Babbage, who in the 1830s took time off from building the difference engine to write a treatise on political economy, based on the observations he made while touring the factories and workshops of England. In On the Economy of Machinery and Manufactures (1832), Babbage explains:

"... the master manufacturer, by dividing the work to be executed into different processes, each requiring different degrees of skill or force, can purchase exactly that precise quantity of both which is necessary for each process; whereas if the work were executed by one workman, that person must possess sufficient skill to perform the most difficult, and sufficient strength to execute the most laborious, of the operations into which the art is divided." (pp175-176)

Babbage took Smith's example of a pin factory and went one better in his analysis: he detailed the precise division of work and the wages paid to each of the workers. Some processes in pin manufacture required both skill and strength; some were so simple that a child could do them — and since this was Victorian England, a child did do them. So the highest paid worker on the staff was a man, at 5s. 4½d. per day; the lowest paid a boy, at 4½d. per day. Which meant, as Harry Braverman points out in Labor and Monopoly Capital (1974):

"If the minimum pay for a craftsman capable of performing all operations is no more than the highest pay in the above listing, and if such craftsmen are employed exclusively, then the labour costs of manufacture would be more than doubled, even if the very same division of labor were employed and even if the craftsmen produced the pins at the very same speed as the detail workers." (p80) [italics in original]

This explains why it makes sense for the proprietor of the restaurant to employ a less skilled person just to peel potatoes and wash the dishes. The proprietor could hire a skilled cook to do this work, but it will be cheaper to hire someone less skilled, preferably the least capable person who can still do those jobs. A skilled cook would be more expensive because their wage is determined by what they could earn elsewhere, outside this restaurant, not by what they do inside. And exactly the same is true of any job done for a wage — a point which (finally) brings us back to software development.

The proprietor of a software development organisation would obviously like to benefit in the same way as the proprietor of the restaurant. They would like to use division of labour, so that they can reduce their wage-bill by hiring a staff of cheaper, less-skilled people who can each only just do their own particular jobs. Wherever people make things in return for wages there will be this pressure. Software is no different.

But there's a catch. In software, is this really possible? Division of labour makes sense in a mass-production environment, but is software development such an environment? The proprietors of the software world clearly wish it were so, but that wish can only come true to the extent that software development is predictable and routine — and for the most part it isn't. Just like other forms of engineering, software development is around 70% repair and maintenance. Repair is never routine, and in software even the initial production is often unpredictable, because it is actually mostly design work, not manufacture in the normal sense. (This is perhaps the main way in which coding differs from cooking: coding is always about process creation, cooking is usually about process execution.)

However, this practical difficulty doesn't prevent software proprietors from yearning for predictability. It might even explain their unreasonable enthusiasm for the Waterfall process over the years. Any process that promises predictability is also implicitly promising a less skilled staff and a lower wage-bill. In contrast, an Agile process is implicitly demanding a more skilled staff and hence a higher wage-bill — because when you don't believe in prediction you need a flexible, broadly competent staff who can step-up and do things that nobody expected. (Of course, to the extent that a particular project really is unpredictable, the Agile enthusiasts will be correct when they claim that in the end their way is actually better, because the less skilled staff would actually take longer and cost more, if they finished at all.)

What started as a tension between the proprietor and the staff over how to share out the newly created value has turned into a tension over skills and competence. Developers might naturally be expected to take a pride in their craft skills, building them up over the years like any artisan. Perhaps the best expression of this desire can be found in open-source software, where there is never any attempt to make the work of creating software routine, predictable or de-skilled. But the difference here is that open-source software is written by hackers for themselves, not for a wage.

Agile processes promise the developers an opportunity to practice and grow their craft skills. Agile processes promise the proprietor nothing but an extra expense, accepted only because predicting the future is too hard. But some Agile processes implicitly make another promise to the proprietor, a promise with a dark side. And I think this dark side is perhaps why some developers are right to be suspicious of the rhetoric of Agile development.

Remember the two ways the proprietor can make more money? I've been concentrating on de-skilling, but there's also the other way: the proprietor can keep more money for themselves if they can increase the productivity of each member of staff, but still pay the same wages. With a given division of labour and a given level of skill, the proprietor can keep more money for themselves if they can get their staff to work for longer each day or to work with greater intensity. And when we deconstruct the terminology used by the most popular Agile process, Scrum, we find an unfortunate allusion to work at a greater intensity.

For example, the week-by-week cycle of development is called an "iteration" in practically every other software process, including Extreme Programming. In Scrum this time period is called a Sprint. What associations does that conjure up? Well when you sprint you make an extreme effort to go as fast as possible, an effort that you can only keep up for a short time. That's what "sprint" means in everyday life.

The list of unimplemented features is just called the "user stories" in Extreme Programming. In Scrum this list is called the Backlog. What does "backlog" mean in everyday life? It's the stuff that you should have already finished. The metaphor is clear: Rush! Rush! Finish it off quickly! You're late already.

Notice that I'm not saying that this is what these names should mean, or that this is what Scrum practitioners want them to mean, it's just that words come with everyday meanings, and people will tend to understand them this way. Imagine if you went to a restaurant and your waiter told you that the proprietor had introduced a new kind of organisation in the kitchen, called Scrum. The kitchen staff now have a "backlog" of dishes to prepare and they are "sprinting" to get them done. As a customer, I think you would take the metaphor at face value. Now imagine that you are a customer or a manager of a software development team using Scrum. Is there any reason for you not to take the metaphor at face value?

So this is the dark side of Agile: the danger that people outside the development team will hear these metaphors and misunderstand them — as a promise of work at a greater intensity and nothing more. Thinking that, apart from that, Agile is business as usual. Still yearning to make more money out of predictability, lower skills and lower wages. Not understanding that the point of Agile is to be Antifragile.

It's easy to imagine, if you were a developer in such an environment, how you would feel, how you would resist. I think when Agile fails, it must often fail in this way.