How Anthony Bourdain sized up chefs

When he wanted to hire a cook, he’d invite a candidate into his kitchen, and issue a single command: Make me an omelette. From that, he could infer everything he needed to know about the chef –– an excellent example of correlating the performance of a highly complex range of tasks from the performance of one (or a few) tasks. Do you know what else performs lots and lots of complex tasks? Software.

What does Anthony Bourdain have to do with CI Pipelines?

Consider this

“What most people don't get about professional-level cooking is that it is not at all about the best recipe, the most innovative presentation, [....] – the real business of preparing the food you eat-is more about consistency, about mindless, unvarying repetition, the same series of tasks performed over and over and over again in exactly the same way. Chefs require blind, near-fanatical loyalty, a strong back and an automation-like consistency of execution under battlefield conditions.” – Anthony Bourdain, Kitchen Confidential

Now imagine this…

• The Jenkins server plays the role of head chef at a busy restaurant

• Developer builds play the role of plates of food

• Jenkins inspects each plate before it goes out to a guest, to make sure it meets the high standards of the restaurant

• Jenkins needs to answer a simple question: is the software (the food), in its current iteration, fit to be delivered to a table?

• Jenkins uses automated software tests to determine a yes or no answer to that question

• If Jenkins can decisively answer that question with say, 10 checks, there’s no need for an 11th check. None at all. 🤓

Automated Tests separate the wheat from the chaff – like a Head Chef inspecting food on a slide check rack

When a developer pushes her code to a repo, lots of checks are performed: source checkout, container scans, asset packaging, JavaScript transpiling, linting, unit tests, integration tests, end-to-end tests, etc. Sadly, some CI pipelines are filled with nonsensical and/or duplicative checks: nb: several consecutive verifications of the non-existence of potato-shaped objects. I’m kidding (a little).

My point is this: some thoughtful individual absolutely has to make sure there’s rational intent behind the choices of which checks to prioritize versus which to deprioritize. In my opinion, this thought process is just applying the Bourdain method to automated testing; eg: how can I spend the least amount of time, yet get the most amount of information?

Asking and answering lots of low-value questions doesn’t add up to answering a few important ones

In 2017, the Atlantic featured a wonderful story about the Pentagon super computer that predicted American victory in Vietnam. The takeaway I gleaned from that story wasn’t that computers are bad. It’s that even smart people can do dumb things when they ask the wrong questions.

Enter Robert McNamara

McNamara was appointed Secretary of Defense in 1961. As a young man professionally groomed at the Rand Corporation, he wanted to apply game theory, economic analysis, and computing to matters of defense. With respect to the Vietnam War, he demanded more and more data from troops on the ground that looked like this…

ever heard of Plato? Aristotle? Socrates? Morons!

People were scared to openly disagree with McNamara because … that’s another story. 🤔

“McNamara's early applications of computers to war were ground-breaking. Using computers as an analytical tool, he soon made fundamental changes in the department's reporting techniques, as well as in the use of computer-generated data for decision making. McNamara's experience was almost exclusively with the use of statistical evidence to motivate and control management decisions.”

- Donald Fisher Harrison (Computers, Electronic Data, and the Vietnam War)

☝🏽How’d that work out? 👇🏽

Attempting to arrive at an important answer by asking lots of unimportant questions is like multiplying 0 by a really large number and expecting the result to be something other than 0.

The Law of Least Effort

Seriously, everyone on Earth should read Daniel Kahneman immediately 🤩.

CI pipelines should follow this law too – without the laziness. 😄

The point of CI is to raise confidence – not inflate the number of checks performed

Some engineers speak and behave as if increasing the number of tests is the goal of releasing software. That’s ass backwards. When software doesn’t work right, users don’t ask about the amount of tests… or the level of code coverage. Their input usually resembles the following: “why the fuck didn’t you make sure this shit worked right before giving it to me?” And when they say this shit – they are not talking about un-used variables, irregular indentation, excessive cyclomatic complexity, or any other such palaver. They’re talking about the features and workflows they care about.

CI should have the disposition of a New Yorker 🗽

As in… always be getting to the point as quickly as possible. By the way, you know who was a New Yorker? Anthony Bourdain.

Going back to the restaurant metaphor, let’s revisit the chef at the slide, scanning entreés and appetizers as they go by. If a quick visual were to reveal a greasy thumbprint on a plate and a piece of an eyelash sticking out of a garnish, that dish would not reach a dining room table. And later, someone would have some ‘splainin to do 😡.

A thoughtful CI pipeline would identify the greasy thumbprints + eyelash fragments before they even got to the build server. We shouldn’t waste electricity building software that’s going right into the garbage. Implementing a low number of smart static code analysis checks, coupled with some git pre-push hooks would prevent developers from triggering builds that don’t meet the minimum thresholds of build-worthiness. For example, a basic code-complexity check (like sonarjs for JavaScript; or radon for python), that enforces reasonable defaults can go a long way in making code much more readable, and cheaper to maintain.

Here’s what 2 smart people say

In the article from which the above quote was taken, another badass is mentioned: Sarah Mei.

One last thing

Many people know Anthony Bourdain only as a chef or entertainment personality. What’s less known is that he started training jiu jitsu at the Renzo Gracie Academy in New York City – at the age of 58.