Software engineering is like cooking

During the last few month I’ve been explaining software engineering to management types quite a bit.  Most of the “bosses” that I talked to weren’t technical at all, so I was trying to stay away from famous concepts, examples, and terminology as much as I could.  Of course, that required some sort of substitute for concepts, examples, and terminology.  I’ve tried analogies from different unrelated areas, and was surprised as how good cooking was fitting the purpose.

Before I go any further, I have to say that I am not a cook and that I don’t know much about cooking.  But.  I know just about the same as any other average human being.  Which, sort of, moves me into the same category with my targets, or “bosses”, as I called them before.

Here are a few examples that worked well.

On the need for maintenance

Once a project, or part of a project, or a feature, or a bug fix has been done in an “urgent” mode, switching back to “standard” mode gets tough and tricky.  “Bosses” that tasted fast development often want the team to stay in that mode for as long as possible.  Dead lines get shorter, pressure and stress build up, and nobody “up” wants to hear about that.  All they want is more, more, and then some more.  Saying something about re-factoring or maintenance period is dangerous in heretical kind of way.

But here comes the analogy from the cooking world.  No matter how much we cooked and how many guests we fed, there comes the time to wash the dishes.   It’s hard to argue with that.  Even when using disposable dishes, there still comes the time to put them all in a large black garbage bag and take them away.  Otherwise the kitchen slows down because of all the mess, smells start to evaporate, and that on its own attracts unwanted insects and animals.  Nobody wants that.  Not in their kitchen, not in their software.

On the need for time planning

More than once I had to explain that four times by one week is not quite the same as one month.  And that’s a tough one to get through without analogies.  When I ask a month for a project or a feature to be implemented properly, I hear back something along the lines of “we don’t have that much time, so do whatever you can in one week”.  And I do.  Once the week is gone, the result is not satisfying of course.  So I hear “OK, get another week and finish this thing”.  If arguing still doesn’t help, we work hard again, and end up with unsatisfactory result a week later.  Then it repeats for another two times, after which I hear “you asked for a month and now you’ve worked for a month, but result is not as good as it should be”.  To which I have to stand the point of four times a week is not the same as one month.

The analogy I use is with time constraints put on cooking a dish.  Ask a chief to cook you something in 5 minutes and you’ll get an omlette.  Give him another 5 minutes to cook you something else and you’ll probably get a salad.  Give him another 5 minutes and he’ll make you a sandwich.  5 minutes more and he’ll hate you a bit, as well as that ugly burger.  Now if you tell the chief from the start that he has 20 minutes – how different do you think the food will be?

Of course, this is more of an excuse rather than an education analogy, but sometimes it works after the second or third attempt.  Which saves quite a bit of time and effort, as well as helps to improve the final result.

And as an extra thought – some things take time, no matter what you do.  Cooking meat usually involves time.  Growing a seed into a tree usually involves time.  Travelling distances between points A and B usually involves time.  Things can be done to reduce the time, but it is impossible to still perform these actions without using up some amount of time.  For each of those actions, there is a minimum.

Another example as a side note, and a very famous one.  It goes something like this: it takes 9 month for a pregnant woman to deliver a baby.  If you take 9 women and get them all pregnant, you won’t get a baby in 1 month.  You’ll get 9 babies.  But they all will take 9 month to deliver.  (yes, yes, I am aware of certain circumstances that could vary the 9 month, but let’s just try to keep it simple, OK?).

On the need for good people

“Bosses” often look at things in terms of costs.  And good people often cost more than bad people (I mean professionally good and bad, not personally).  Costs are very measurable.  However, the difference between a good software engineer and a bad software engineer is not always that measurable for the “bosses”.  They just don’t see the difference often.  Especially, if there is a team of people.  Especially if this team is abstracted from the “bosses” by a team leader or an IT manager.  That would often end up with a conversation of why do we need this guy and how can we replace this expensive guy with that cheap guy.

Again, cooking t the rescue.  Have you tried a dish cooked by a person who knows what he is doing?  It was delicious, wasn’t it?  Now, have you ever tried a dish cooked by a drunk bachelor?  For himself?  That probably involved spaghetti at best.  What’s the difference between these two types of cooks?  You’d pretty much always prefer the food cooked by a professional.  It’ll cost you more, yes.  But you’ll know for sure that it’s safe to eat, and that more than that, you’d enjoy it too.

Can you replace a pro cook in the kitchen with a drunk bachelor, so that nobody who eats notices the difference?  Better even, can you replace one pro cook with a few drunk bachelors without anybody noticing it?  Chances are that you’ll probably get even worse results with a few bachelors than with one.  But in either case,  the change of cooks will be obvoius.

On the need for detailed specifications

“Bosses” often oversimplify things.  For them, “build a web site” or “make this thing work” is often a clear enough job description.  Explaining that more details and information is needed is often tough.  Burring them in questions even doesn’t always work.  At that stage, even prototypes are a bit of an unreachable target.

Here comes a cooking analogy.  If you order a “piece of meat”, you’ll probably get one.  However, it’s about as much as you know about the dish that you will get.  It can vary a lot from barbeque to steak to roast.  Tempreture, size, sauce, serving, timing, etc, etc, etc.  There are just too many ways of understanding a “piece of meat” order.  And then there are so many ways of cooking one that results are most likely to be unpredictable, and most often not satisfying.  “I wanted it with barbeque sauce and a little mashed potato on the side of a plate!”

The more you can tell a chief (or a waiter for that matter) about the food that you want to eat and the way you prefer it to be cooked and served, the more likely you are to get what you want.  Of course, that means that you need to think a bit about what you really want, and then try to communicate it to another person.  However, the result is often worth the effort.  Especially, if you are somewhere you’ve never eaten before.

On the need for the tools and methods to match the team

“Bosses” are often targeted by marketing departments of vendors, big and small.  “Buy this tool for your IT department and it will be 20% more productive”.  “Implement this approach and you will have lower TCO”. “Do this and you’ll get that”.  Arguing back is tough.  Marketing people speak “bosses” dialect much better than technical people do.

So, cooking analogy comes in place.  Who should decide which knife to use?  Who should decide which groceries to get?  Who should decide on the temperature and timing?  Is it the person who orders the food, or the cook?  Every cook knows what tools he needs to cook a dish.   You can choose the tools for him, yes.  But then it very much depends on how good you are at cooking yourself and how close are your methods to methods of your cook. Best cooks, of course, will manage anyway.  But why would you want to get yourself into that risky situation?  Get yourself a cook, ask him what he needs to do the job, get it for him.  If hiring more than one cook – you can try to make them use the same tools.  Sometimes it works (most of them will use knives), sometimes it doesn’t (cooking desserts is different from cooking sushi).  Let them decide.

These are just some of those that I use.  And sometimes I vary the above ones too.  They are here just to illustrate.  YMMV.