These few last weeks I've been doing a number of unrelated things: I watched Master Chef on BBC LifeStyle, finished Fallout: New Vegas then started to play Titan Quest, finished a book from 37signals and another from Microsoft Press about project management, and finally spent time reading blog posts on some various famous IT heroes.

In some perverted way it all makes sense.
So, what's the common idea between these seemingly unrelated elements? Well, the common element is the notion of recipe.

Cooking

A recipe basically is a list of actions to follow in some pretty strict order to achieve a particular result. Following a recipe you could for example manage to cook an egg.

The important point is that even if you follow the recipe accurately, you may still fail to prepare something tasty: Perhaps the type of ingredients available was not exactly matching what the author of the recipe had in mind, your rice should have cooked longer - or perhaps not that much. The temperature of your stove may be slightly different than what the controls indicate, or simply you were not that good at preparing the sauce.

The idea here is that even when you have a very accurate recipe you still need some skills and some brain to actually understand what you are meant to do. Possibly the indication about requiring one litter of olive oil was a typo, perhaps it should have been one decilitre instead. Who knows ?

Watching Master Chef is really a pleasure.

Far from being some kind of sadomasochistic contest orchestrated by a spawn of Satan, you find instead a relaxing setup with people who really try their best to show their ability at cooking, their imagination in how to combine flavors, they have to deal with various real constraints like list of ingredients to use, quantities, time limits, appearance, etc... they are not directly competing against each other and trying to find who else they will vote against. No, they are here to show what they can do and impressed the show's hosts.

Just watching the results sometimes just makes me want to lick the tv screen.

Titan Quest

So, how does the cooking relates to Titan Quest?

Well, Titan Quest is what you can call a Diablo 2 Clone. Technically you could call it a Diablo 2 rip-off, because really even if there is a difference between inspiration and copy, that one is definitely in the grey zone:

• Third person 3d game with fixed view point: Check
• Gazillion of items of different quality (normal, magic, rare, set, ...): Check
• System of collectible power-ups you can attach to items to give them additional magic properties: Check
  
• High pitched *ping* sound when a magic ring fall on the ground: Check
• Town portal: Check
• Merchant to sell your crap but that have almost nothing worth buying: Check
• Fantasy setup with mythical creatures: Check
• Three acts in various countries: Check
• Dungeons and caves here and there along a linear path: Check
• Side quests unlocking areas: Check
• Levels, skill tree, health and energy bars, electric, poison, fire, etc etc...: Check
• Groups of random monsters guarding chests in the middle of nowhere: Check
• Whole map repopulating when you reload the game: Check
• ...
  

I could continue like that probably for a while. Basically I wonder why Blizzard bothered making a new engine for Diablo III, they could just have asked nicely IronLore to gave them the engine - or sue their ass -, because well it's a nice looking clone. There are of course some differences: It's using the Mediterranean area for the setup, it's not scary, it's way too easy, and the biggest flaw - It's not super exciting. It's borderline boring.

So that was an example of cooking: They probably decided to create a game that would be "like diablo" (but better), made a bullet point list of the things they had to have, probably thinking that would be good enough, but in the end it terribly lacks of flavour. It's not bad, far from it, but it's just bland.

Obviously Blizzard is still the best company when the objective is to create a Blizzard game.

It's interesting (I think) to make a comparison here with Fallout: New Vegas which despite being built from the Fallout 3 game, using the same engine, same animations, same graphics (mostly), still managed to feel much more different, and as I previous wrote: Much more rich despite using the same base ingredients.

Basically the difference in the two cases is that IronLore was not able to identify what made Diablo what it was, while Obsidian was able to identify the core values of what a Fallout game should be.

Software Development Methods and Start-ups

The same kind of "recipe" concept exists in the programming domain.

Despite people warning about Silver Bullets for decades, we still have books offering miracle methodologies (Agile, TestDriven, Extreme, ...) pushed forward by evangelists and their associated software ecosystem (issue trackers, iterations managers, planning poker games, release managers, continuous integration/building/regression tools, white boards or post-it notes, ...); miraculous languages (scripts, web-based, virtual machine based, functional, run-everywhere, easy, fast, magic); programming methods (object oriented programming, design patterns, ...); that are going to solve all our past, present and future problems.

And the equivalent exists for how to create your own company and be rich and successful, with lists of do's and don'ts.

The really annoying thing is that all these authors really believe that what they evangelise is the only true word, that it would work for everybody everywhere, and that if it does not work for you then it's because you are doing it wrong.

Well, call me whatever you want, but I don't believe this is true at all.

All these methods are just recipes, tools, that may apply in some particular case but would probably not be suitable in some other.

The difference between a good and a bad programmer for example is not really based on how good he masters a particular domain. What make him good is the set of accumulated knowledge that allows him to know when and how to use something, and when and how to use something else. And possibly when not to do something at all and ask somebody else to do it.

I would not do web programming in C++. It can be done, but for fast changing data C++ is probably not the best choice. On the other hand I would probably not use an interpreted language to do performance computing - except if benchmarks shows that the virtual machine is actually performing as good or better as native code. I would not use COBOL or Fortran as my shell script of choice either. And Visual Basic is probably not the best choice to make portable applications.

I think the biggest deception so far for me has been the whole Agile processes (count in it everything from Scrum to XP). Most people are following a list of things to do (iterations, backlog, velocity, points, whatever), but they are still not doing it right. The important is not all this crap, the important in the end is to deliver what the users need¹, on time.

Everything else is just a way to get there, and as long as you reach the end objective it does not really matter how you do it.

Proving myself wrong

Just for the sake of doing exactly what I said was wrong with all these people, I will now give my list of things I think should be done and should not be done when you are doing software development!

What you should really have:

• A source control system, with a continuous build system that detects the build errors and failed tests, and informs whoever broke them.
  
• Some mix of Unit Testing for the core elements on which everything is built, and some Function/Regression Testing to validate and test the high-level systems and applications.
  
• Your code-base should build at the highest possible warning level, with warning as errors. Else you are going to miss problems.
  
• Everything that can be automated, should be automated.² The more manual operations you have to do, the more you risk to make mistakes or waste time.
  
• If you can find a good existing third party library or tool that matches your needs, just use it instead of writing your own.
  
• Release often, make sure the deployment process is streamlined, make sure that your users don't waste time when trying your new versions, make sure you can get feedback easily.
  
• Fix the issues (crashes, performance and usability problems) first, add features next.
  
• Have a small team of experienced and motivated people that can work together.
  
• Identify your production and organization bottlenecks and fix them.
  

What you should avoid:

• Apply any particular list of things to do without actually understand why you have to do it, or if it even applies to you at all in first place.
  
• Hire more people to go faster.
  
• Keep bunches of semi-redundant tools and subsystems instead of merging and consolidating them.³
• Changing all your processes at the same time to adopt a new one instead of just incrementally change what does not work.
  

I could probably add rules like that, but the bottom line is to use your brain and try to be smart.

For example the rule about not adding more people is not an absolute rule, it depends of what you hope to achieve: If it takes 30 minutes to cook a meal, adding more cooks is not going to help you eat earlier. But if you have more cooks, you can instead have some of them work on the main course, other prepare the dessert, while the last ones are doing the starters, or you can have them help preparing a number of meals at the same time.

So yeah, there's a lot about cooking you can apply to software development.

---