Code Like a Chef: Layer Simplicity

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”

John Gall

This is dish from the five course meal that my best man, Rene De Leon, prepared for my wedding. Rene is a world class chef: over the last seven years he’s worked at the first, second and seventh best restaurants in the world, and currently serves as sous chef at Next, the 2012 James Beard Award winner for Best New Restaurant in America.

Though it’s a complex dish, there’s nothing complicated about making it: place thinly sliced potatoes in a single layer on a sheet tray, drizzle olive oil, salt, and roast until GBD - “Golden Brown Delicious”. Trim, salt, and saute green beans. Give pork a 12 hour salt-water bath, dry it, sear it, thow it in the oven.

The complexity of the dish comes from layering simplicity. The ingredients are common vegetables and meat purchased at the Pike’s Place Market. The techniques - roasting, slicing, sautéing, saucing - are thousands of years old, yet are still used by anyone who’s ever tried to cook Thanksgiving dinner.

This was the most surprising part of my culinary education: great chefs aren’t great because they do complicated things, but because they ruthlessly execute on simple tasks, and then combine the results. Alinea has a dish with 86 components, yet co-owner Nick Kokonas maintains in the Alinea Cookbook that, “there lies the real surprise to these recipes: none of the techniques is difficult taken alone.”

Though counter-intuitive, my progress as a developer is marked by my ability to write simple code. When I was first learning Ruby, I wrote big messes of spaghetti code - every method was trying to do too much, and I was trying to be too clever. Coming back to it now, the code is hard to test, hard to maintain, and hard to understand.

Today, I try not to have methods longer than five lines, and I try not to cram too much into a single object. Bob Martin calls this the Single Responsibility Principle - the idea that “A class should have one, and only one, reason to change.”

In The Pragmatic Programmer, Andrew Hunt and Dave Thomas write:

“Early on we are taught not to write a program as a single big chunk, but that we should ‘divide and conquer’ and separate a program into modules… It’s easier to write relatively small, self-contained components than a single large block of code. Simple components can be designed, coded, unit tested and then forgotten - there is no need to keep changing existing code as you add new code.”

Simplicity is easy to delegate. It’s easy to train the new employee on. It's easy to iterate upon. It’s hard to do complicated things consistently well, but with practice, you can master simple techniques.

Layering simplicity yields rich results. I’ll leave you with these pictures of the wedding cake Rene made for us. He called it a “Fruit Opera”, and its flavors were anything but simple.