The taste test

Imagine you’ve just been given a new cookbook. It has a recipe for Oysters Rockefeller that a friend recommended. Really it could be anything but oysters have been in my media for the last week so we’ll go with them. You buy the ingredients, prepare them carefully, cook and serve. It looks great, you take a picture. When you taste them they’re horrid, little metallic salty nubbins.

What went wrong?

• The wrong ingredients – Do you need fresher oysters? Maybe different herbs?
• The wrong technique – Should the topping be cut finer? Was it cook too much or not enough?
• The wrong recipe – One from the book, or the internet, or the telly?
• It all went wrong – Maybe the bad taste isn’t a surprise after the nightmare cooking process.
• Maybe you just don’t like oysters – However you make it from some people just don’t like oysters.

A software engineering metaphor

What am I trying to say here? Is the recipe an algorithm? Why did your friend recommend oysters?

The message here is sometimes you try something and, in the end, the final result isn’t what you want. It may even look good but it might not taste good. You need to be able to judge that final result and think why it hasn’t worked. You might be able to fix it or you might not. If you can’t untangle why then you probably won’t be able to fix it. If you don’t like the taste then no one else gets to tell you your wrong, you like it or don’t. Equally, just because you didn’t like these oysters doesn’t mean you won’t like any oysters.

Who gets to taste

In this metaphor a lot of people get to taste the oysters but the oysters are a different thing in each case:

• The customer – They want a finish product that works. They probably had some sort of specification but that’s just what they said they wanted. Does it do the job that they really needed it to?
• The users – They want a finished product that works for them. The users of the system may or may not have had any direct input into the specification. There is a difference between the idealised situations in the documentation and the actual situation on the ground.
• The managers – They ran the project and hope it all goes to plan and within the budget. Did they suddenly needed to grow the team or push the release back passed a deadline. They might also need to be able to change things as the specification is updated or resources change.
• The developers – They actually designed and build the project. They probably want reasonable hours without any crunch. Having a codebase they can understand and that isn’t brittle under changes. Maybe they want to be able to try new tools and languages. Maybe they want to stay with what is familiar to them.

Any of these people can separately not enjoy a project for a number of reasons. If the customer doesn’t like it are they going to keep providing the money. If the managers don’t like it then everything can get turned upside down next time. If the developers don’t like it are they going to look for work elsewhere. If the users don’t like it they may end up having to lump it. Pity the poor users whose tools are forced on them from above.

What to do about the the taste

I wrote about retrospectives recently, they give you a chance to discuss what happened and whether it was good or bad. Typically that’s fairly fine grained, was something good or bad in the last sprint. Here we’re thinking about a longer timescale. While this sort of discussion can go on in a retrospective it might benefit from a separate discussion. This could be a project post-mortem but that can be a long time to wait to learn a lesson.

In the end

As a kid I didn’t like mushrooms. At home I would carefully separate them out from a dish. I remember going to a Chinese restaurant, eating from the European menu and still not eating the mushrooms that came with the dish. Eventually I decided to start eating my mushrooms at the restaurant. I carefully ate them with other things to taste them less. That was many years ago and now I think mushrooms are great. Really great, different sorts of mushrooms cooked in different ways.

At university function programming was a bit of an oddity. It was used in research but I don’t know how much it was being used in real world projects. Now I’ve read books about function programming in C++ and C#. They look at practical application of function programming and why it can be a good idea. It’s definitely something I think about with new projects.