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…
# Excerpt from Situation Report Army File (SITRA)
# May 20, 1966 - December 28, 1968
Loss ratio (personnel) Contains the ratio of friendly to enemy personnel killed in action expressed as a mixed number (two whole numbers and two fractional numbers without the decimal point), and implies the number of friendly personnel killed per each enemy killed.
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.
“When the Nixon Administration took over in 1969 all the data on North Vietnam and on the United States was fed into a Pentagon computer—population, gross national product, manufacturing capability, number of tanks, ships, and aircraft, size of the armed forces, and the like. The computer was then asked, “When will we win?” It took only a moment to give the answer: “You won in 1964!””
The Law of Least Effort
Seriously, everyone on Earth should read Daniel Kahneman immediately 🤩.
“If there are several ways of achieving the same goal, people will eventually gravitate to the least demanding course of action. Laziness is built deep into our nature.”
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
“Monitoring everything is an anti-pattern. The same is true of testing. One simply cannot and should not try to test everything. [Automated testing is...] a best effort verification of the system — and making smart bets and tradeoffs given our needs appears to be the best way forward.”
In the article from which the above quote was taken, another badass is mentioned: Sarah Mei.
“The writing and running of tests is not a goal in and of itself” — EVER. We do it to get some benefit for our team, or the business. If you can find a more efficient way to get those benefits that works for your team & larger org, you should absolutely take it.”
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.
“Every once in awhile I get to feel the will to live drain out of a 23-year-old athlete. That’s enough for me.” – Anthony Bourdain.