This is part 2. Part 1 is here.

So this is where the software development as a restaurant analogy starts getting a little weird. To be fair, these examples are more quirks of the industry more than the profession itself.

A customer at a restaurant

Customer: “There’s a fly in my soup”
Waiter: “Oops, that must mean there’s a fly in everyone else’s soup”
Customer: “What are you going to do about it?”
Waiter: “Well, if it’s a big enough fly, tomorrow’s soups will not have it. Otherwise everyone will have to live with it for a few months.”
Customer: “Eh?”
Waiter: “Well, even after a few months, it’s a Maybe. Depends on if there are also roaches in the soup”

If you’ve ever watched a restaurant service challenge on Masterchef (try the Australian one, it’s much better :P), producing dishes for a bunch of people is back-breaking work. Even if it is the same dish over and over again. If we think of software as food, producing a copy of the software requires little-to-no effort. One consequence of this is if there’s an eggshell in one dish, all versions of that dish probably have the eggshell too. The exact same one.

Not all eggshells are created equal though, a single dish has a unique combination of flies and eggshells. Some are known, and some are yet to be discovered. There’s an ongoing struggle in the kitchen between removing the undesirables, and adding more flavour to the dish. Or some other dish variation…

A customer arrives at a restaurant.

Waiter: “Welcome Madam, we have the clam chowder, Florentine steak and vegetarian lasagne available today”.
Customer: “That sounds interesting. I’d like a clam chowder, but I’m actually lactose intolerant. Can you do something for me?”
Waiter: “Certainly Madam, but you will have to come back later. Maybe we will have it on the menu by then”
Customer: “How much later?”
Waiter: “Maybe a few months. Maybe a year. It depends. In the meantime, maybe you can try removing the cream yourself.”

If you’re in a restaurant, you’re expecting some flexibility. Small variations are taken for granted. In a software restaurant, since you’re getting copies of stuff, you’re not getting changes until the “master” copy is updated. When does the “master” copy get updated? Remember that we’ve already got flies to squash and eggshells to remove, in addition to flavours to add. And that’s not the only problem.

In the kitchen

Waiter: “We have 100 more orders of the clam chowder coming through.”
Cook: “The clam chowder from last month is the one you want. Just make a 100 copies of it. You know where the food cloning machine is.”
Waiter: “Guys, there’s lots of flies in that one…”
Cook: “We’re trying to fix the recipe. We only have the old one to work with. It’s a hundred pages long, full of corrections and hard to know what’s needed for what taste anymore.”
Waiter: “Do we have something for lactose intolerance?”
Cook: “Erm… maybe in a few months. Could they take out the cream themselves?”
Waiter: “Seriously?”

Software developers aren’t really cooks. They “cook” the “master” copy of the dish, but really, they spend most of their time refining recipes. Software developers are more like recipe authors than cooks. Except the recipes are hundreds of pages long, often passed down from generation to generation without much explanation; and steps interact with each other in strange and wonderful ways, where it can magically give rise to eggshells and roaches along the way.

Just think about what kind of process someone refining recipes has to go through to “test” their recipes! Say you’re trying to refine a recipe. Maybe make it more spicy, for your friends from Indonesia. How would you go about doing it?

If you’ve tried to put a dish together, and had to improvise, you know how hard it can be to work your way back to what went into that one amazing dish. When you’re trying out different things, sometimes it can be hard to keep track of what taste was the result of what magic ingredient you added. And you can never create that one amazing dish. Ever again.

In the kitchen

Waiter: “Someone’s found a roach in the lasagna”
Cook: “Did it come from the bechamel sauce?”
Waiter: “Maybe. How would they know?”
Cook: “If it did we may have a bigger problem. That bechamel sauce is used in the fish pie and croquettes as well.”
Waiter: “So they’ve all got the roach?”
Cook: “Yessiree. Actually if they don’t have it, it means it’s a problem only with the lasanga recipe, not the bechamel”
Waiter: “Seriously?”

In any normal kitchen, if a batch of sauce is bad, you just make a new one. In a software kitchen, if a sauce is bad, everything it’s gone into is bad. Every single dish with it. And there’s nothing to be done till the sauce recipe is fixed.

It also highlights a problem common to both kitchens. It’s sometimes pretty hard to figure out what caused a problem! (Think masterchef taste test… what went into a dish to cause a particular taste?)

Surely this can’t be the way software is made! There’s got to be food inspectors coming in occasionally right? Well… tune in next time to find out why, despite what seems like a pretty crummy state of things, more established software kitchens have their own secret sauce recipes … for making secret sauces…