"When you want to influence the world around you, make sure that your action is causally connected to whatever you want to influence."
How can we know when an action is causally connected to an effect? Western philosophy since David Hume has struggled to find a solution to this problem. The 'problem of causality' is that it is extremely difficult to establish cause and effect with any degree of certainty. All we have is correlation. Modern thinkers (e.g. Judea Pearl) are still grappling with this problem today.
Like many philosophical problems, regular people solve the problem of causality by plugging up their ears and saying "lalala, I'm not listening." And then we get crap like analytics marketing teams.
Sometimes it's hard to identify a broken chain on the spot and a lot of marketing tricks are based on that. Highly recommend you to read Freakonomics if you haven't yet.
Also this article mentions two observations of Richard Feynmann and I just can't stop admiring the curiosity and wit of the man. His biography totally inspired me and made me laugh a lot
The Scream Test: If you see something and you don't know what it does, remove it and see if anyone screams.
Chesterton's Fence [0]: "reforms should not be made until the reasoning behind the existing state of affairs is understood" (Though the purpose of this fence is not obvious, there may be valid reasons for its presence.)
There were a few times in the development of Apache CouchDB where whole features were “accidentally“ removed as a way of pointing out that the test suite didn’t exercise them.
I would interpret them at saying, "if you don't know why something is there, break it", and "if you don't know why something is there, don't break it"; how are you interpreting them, then?
Yes, that's deliberate. As others have said it depends on the context and the ease of reversibility / consequence if it's still in use. I see them as complementary.
If the risk is low it may be simpler/quicker/more cost effective to turn it off and see if anyone screams. So long as you are listening for the scream and can easily turn it back on. Obviously this can be abused but there are times when it is useful.
If the risk is high, definitely spend the time to understand why, even if it is non-obvious.
I always apply Chesterton’s fence before breaking rules and regulations: if I see what the rule intends to accomplish, I can make sure to accomplish the same thing in another manner (walk across the street even if there’s a red light if there are no cars around). If I don’t see the point of the rule, I’m hesitant to break it.
I apply the scream test when refactoring. Comment out a feature and wait until someone complains. After half a year or a year start removing things. Works pretty well. This works better with internal systems. I wouldn't do it with external customers or at least only with a lot of thought.
This may still be a win if the removed feature was one that made future changes difficult. The code bade I spend a lot of time working on has some old/weird features that it seems exist only to be tested but nobody is using them.
But when asking the users you rarely get told to go ahead with removal.
This is a false dichotomy. If you're unsure of usage you could just instrument your code to log method calls and use that analysis to inform what maybe should be removed, but only if you first understand why.
I go through a regular cycle of this at work. Hit a quarter end, encounter some weird thing which only happens at quarter end, add a special case to handle it, a month later, forget about it, delete it, hit another quarter end ...
> The Scream Test: If you see something and you don't know what it does, remove it and see if anyone screams.
Spoken like someone who works on pure software, with Undo!
Out in the physical world, the screaming would be followed by a loud crash. You don't touch anything if you don't know what it does. That's how equipment is destroyed, and people die.
Meh. If you take the average of everybody's nose length, you still have a better estimate than just pulling a number from thin air.
Also, the inhabitants' action is basically what scientists do all the time when they run experiments. Correlation is not causation, but quite often it is a good lead.
More importantly, it sounds like everyone who's going to actually see the statue got a chance to provide their input. So this method maximizes the number of people happy with that part of the sculpture, anyway!
They should be prioritizing count (I mentioned that was the performance metric). They actually wouldn't need to "make sure all their nails weigh the same", only that on average they weigh as much as the template. If you can't save time by using less material, and you can't save time by generating fewer units, might as well make the foundry mold match the template, no?
These things actually do exist. I couldn't quote them for you but nails are designed to meet a specific function and are stated to meet that function under some penalty. For instance penny nails used for framing a house are made to be somewhat malleable so they don't shear when the house settles. This is certainly regularly tested.
Well, but the standards do include both very tiny and very large nails, as they are actually needed by various purposes; and prioritizing by number or weight will still incentivize the facturies to overproduce either small upholstery nails or huge railroad spikes (both of which would be standard-compliant), and disincentivize them from producing medium sized carpentry nails.
Certainly the practical issue of what to use as performance indicator is a deep one, at least if one wishes to have a system that efficiently satisfies the needs of the population rather than their stated wants.
Today we could probably build some decent abstract indicator out of a myriad of detailed statistics, but the soviets didn't have much IT infrastructure in place and had to make do with simpler indicators. The linked memoir has the following summary of how the planned economy worked in practice:
> The Soviet manager’s success indicator was a measure of gross output, such as weight, quantity, square feet, or surface area. [...] The Soviets experimented by adding other indicators, but in the end a gross output indicator always determined the manager’s success or failure.
> Soviet managers were as autonomous as their market counterparts. They set their own plan targets by disguising their productive capacity and overstating their resource needs. Soviet planners served primarily as supply agents for enterprises, endeavouring to supply the enterprises with sufficient inputs to fulfill their gross output targets. The system of material supply could seldom perform this task, and Soviet factory managers made barter arrangements with one another and produced their own inputs. This activity led me to the conclusion that the Soviet economy, like a market, was organized polycentrically and not hierarchically as a planning system. The “central plan” was little more than the summation of the factory manager's individual plans.
I would caution that this account seems like it overstates the actual independence of the managers, no doubt there were many political restrictions on their freedom of action in practice, but the general account that the plan essentially comes from the low level managers seems sound.
They funny thing is that we haven't had a planned economy where everybody was honest. In the communist states everybody was lying and everybody knew that everybody else was lying. And the planners were ignoring this. This makes me wonder how things would have worked out with more honesty.
I don’t know if you can have a planned economy with honesty. The incentives are all messed up. Hell, you can hardly have a natural economy with honesty. Even with the natural balances that don’t exist in a planned economy.
For a much more detailed fictional but based on true events take, there is Francis Spufford's novel Red Plenty. It details how certain factions in the Soviet Union had considered the optimisation problem (including Kantorovich, the inventor of "linear programming"), and were effectively proposing pseudo-market systems. So long as these could be made politically acceptable by not having anything labelled "price".
> what should the central planners give as metrics? Is there anything that works?
According to Goodhart's Law, no. As he originally explained it: "Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes."
Metrics of GDP, inflation, and employment are commonly used in macroeconomics to approximate quality of life, but they're subject to the same problem. For instance, you may be able to increase GDP and employment by increasing violent criminality, expanding the markets for private security, insurance, weapons and prisons, but harming general quality of life.
Have quality control that verifies the nails meet specifications, and only reward production of good nails. It's better but still lacks normal market feedback.
The system as described actually worked fairly well in an economic sense for a few decades, pulling Russia up from a poor agrarian country to a much wealthier industrialized country. In the 1950s there was a legitimate case to be made that Communism was winning and would soon beat capitalism at its own game. Essentially, if the recipient of the nails had their own large-scale industrial project to complete they could pull strings with the Central Committee to make sure they got the raw materials they needed to get their own bonuses. There wasn't much representation of end consumers, so they tended to get low quality stuff that they didn't want, but the system was actually quite good at producing increasing amounts of steel and cement. However increasing disillusionment and corruption, combined with the complexities of a computer-age economy lead to the gradual erosion of the system. There was a bona fide attempt to build a computer model to gather all the relevant inputs and do the central planning, but it didn't get very far in practice.
The book Red Plenty gives an informative and compelling lightly fictionalized account:
> Now I wonder: what should the central planners give as metrics? Is there anything that works?
No. You can't set a metric and let the metric do your governing for you. There needs to be a human in the loop. In other words, the system has to be run by people who are making a good-faith effort to achieve the real objectives.
Markets partly solve the problem. You can have a market economy that optimizes the production of nails and other widgets according to the metric of profit, but if that's all you have, you will end up with corporations that produce lots of widgets at a huge profit, but in the process burn out workers, pollute the environment, and fill news channels with scandals about how Acme knew for the last thirty years that its products were poisoning consumers, but kept the truth hidden. So you need regulations to mitigate these problems. But this in turn requires that the regulators are acting in good faith instead of trying to game a metric. There always needs to be someone in the loop.
You see this in every field, including IT of course.
My favourite example of this was the introduction of the Microsoft Distributed File System (DFS) service into a customer environment. We were only using the DFS Namespaces feature, which is like DNS for file shares: the client downloads a blob of metadata and uses it to find an underlying file share for a logical name. The caching is very effective and the additional delay is negligible.
They had a file performance problem. So of course, they point the finger at the last thing that has changed in the environment: DFS! It must be DFS! I calmly point out that if the performance is bad after a connection has been made, it can't possibly be DFS, it's out of path after the initial negotiation. It's like blaming DNS for slow downloads. Makes no sense! But nope. They just won't accept that. It's the last thing that has changed!
I came back a week later to discover that instead of 2 redundant DFS servers, there are now 6 redundant DFS servers "for performance". To their surprise however, the file shares are still mysteriously behaving poorly.
They dragged me along to a meeting with a cast of thousands to discuss the issues. One guy spent most of the time arguing for increasing the number of DFS servers to 8, 10, or perhaps even more to solve the issue!
Meanwhile I'm having a side-conversation with the storage guy, who sheepishly admits that 3 out of 4 fibre channel paths were down, and this started at about the same time frame as the deployment of DFS. I point this fact out to the room. Everyone looks at me while blinking slowly. A few more moments of silence pass. Then someone helpfully suggests adding more CPU and RAM to the DFS servers. Maybe 8 processors and 64 GB will do the trick!
In this particular case it was "politics" in the smallest sense of the word. The head of the storage team did not get along with the head of the infra team, so the infra guys would solve the problems they could solve, ignoring any storage subsystem problems because that was a "dead end".
This is exactly like the boy looking for the coin under the light. It feels like it could be productive, versus definitely not being productive. It doesn't matter that logically it won't work, it's the feeling that matters.
Sometimes it isn't a matter of people getting along. People don't want to see their pet project take the blame for a failure or completely replaced/defunded, Instead of rationally looking at root causes with facts, people may make emotional responses that are dressed up as logical suggestions (e.g. throw more memory and cores at the problem).
A few years ago, i worked on a payment processing system for a high street bank. The system, in its first stage of evolution, would receive a file full of payment instructions, parse each one, validate it, then pass it on to a gateway in a special binary format.
An architect had decided we should build this as microservices, coupled by message queues. There was one microservice which split the file into records and parsed each one, one which validated each one, and one which handed off to the gateway.
In the first demo of the system, it took half an hour to process a file with a few thousand instructions in it. This was a ludicrous amount of time: it really should have been done in seconds.
The team met, and one of the senior developers pronounced the solution: since this was a microservice system, we would simply split one of the microservices in two, so we could scale out the amount of hardware we were using. The service selected was the first: rather than splitting and parsing the file in one pass, a first microservice would split the file into chunks, and pass each one onto a second microservice, which would parse them.
I asked where we thought the problem was, why we thought splitting a service would help, how we would measure the improvement, and, moreover, why we thought that adding a network hop would make things faster rather than slower. My questions were rejected as self-evidently unnecessary: it is well-known that you can improve the performance of a microservice system by scaling out.
The service was split. There was another demo. It was just as slow as before.
The project was removed from that team, and transferred to a new team under my leadership.
(this is a true story; the one fact omitted for the sake of drama is that the transfer of the project wasn't due to the embarrassing demo, it was purely down to staffing and logistics)
I look forward to analyzing the sequence of physical forces that connect me wanting to tell someone something to keys being pressed on a keyboard to an email showing up in their inbox as part of my decision process at work.
We don't have time to analyze entire chains so we make assumptions about chains that should be unbroken. Occasionally but inevitably we make wrong assumptions.
> but none of the townspeople know anything at all about the emperor’s nose, so the causal chain from the actual emperor’s nose to the elders’ estimate is broken.
They do. They are humans, and humans have noses.
Using the statistical method decreases the chance that a wild guess by the sculptor ends up angering the Emperor and causing deaths in the village.
I don’t think the sculptor was planning to sculpt an outlandish alien nose. The problem is that if your statue doesn’t look right heads will roll.
The story isn’t about the selection of outlier data points as being representative - its more about drawing conclusions through seemingly plausible sounding methods that are nevertheless completely disjoint from the thing you’re reasoning about.
57 comments
[ 1.9 ms ] story [ 118 ms ] threadHow can we know when an action is causally connected to an effect? Western philosophy since David Hume has struggled to find a solution to this problem. The 'problem of causality' is that it is extremely difficult to establish cause and effect with any degree of certainty. All we have is correlation. Modern thinkers (e.g. Judea Pearl) are still grappling with this problem today.
Pearl's fascinating talk on this subject at PyData 2018 is available on YouTube: https://www.youtube.com/watch?v=ZaPV1OSEpHw
Also this article mentions two observations of Richard Feynmann and I just can't stop admiring the curiosity and wit of the man. His biography totally inspired me and made me laugh a lot
The Scream Test: If you see something and you don't know what it does, remove it and see if anyone screams.
Chesterton's Fence [0]: "reforms should not be made until the reasoning behind the existing state of affairs is understood" (Though the purpose of this fence is not obvious, there may be valid reasons for its presence.)
[0] https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence
Option one assumes that you can easily reverse your action with no damage done, which very often isn't the case
If you applied the "Scream" test for a component you don't know what it does in an airplane, it might fall/explode/whatever.
If you do it in a non-critical codebase, it might just break the build, and have someone call you for it.
In the first case, the Chesterton's fence caution is more advisable. In the second, you could go with a "remove it and see what happens" approach.
If the risk is low it may be simpler/quicker/more cost effective to turn it off and see if anyone screams. So long as you are listening for the scream and can easily turn it back on. Obviously this can be abused but there are times when it is useful.
If the risk is high, definitely spend the time to understand why, even if it is non-obvious.
But when asking the users you rarely get told to go ahead with removal.
I imagine that none of the people criticizing the idea worked for long on any large organization.
Or what they worked on was too important for this risk to be taken. In my case, people could have literally screamed.
Spoken like someone who works on pure software, with Undo!
Out in the physical world, the screaming would be followed by a loud crash. You don't touch anything if you don't know what it does. That's how equipment is destroyed, and people die.
Also, the inhabitants' action is basically what scientists do all the time when they run experiments. Correlation is not causation, but quite often it is a good lead.
They averaged everyone's estimate of the emperor's nose.
Now I wonder: what should the central planners give as metrics? Is there anything that works?
(e.g. a 2-inch finishing nail weighs 0.79 g; if a factory reports 1 mil units, take a random .8 kg sample, check if there's ~1k nails).
Certainly the practical issue of what to use as performance indicator is a deep one, at least if one wishes to have a system that efficiently satisfies the needs of the population rather than their stated wants.
Today we could probably build some decent abstract indicator out of a myriad of detailed statistics, but the soviets didn't have much IT infrastructure in place and had to make do with simpler indicators. The linked memoir has the following summary of how the planned economy worked in practice:
> The Soviet manager’s success indicator was a measure of gross output, such as weight, quantity, square feet, or surface area. [...] The Soviets experimented by adding other indicators, but in the end a gross output indicator always determined the manager’s success or failure.
> Soviet managers were as autonomous as their market counterparts. They set their own plan targets by disguising their productive capacity and overstating their resource needs. Soviet planners served primarily as supply agents for enterprises, endeavouring to supply the enterprises with sufficient inputs to fulfill their gross output targets. The system of material supply could seldom perform this task, and Soviet factory managers made barter arrangements with one another and produced their own inputs. This activity led me to the conclusion that the Soviet economy, like a market, was organized polycentrically and not hierarchically as a planning system. The “central plan” was little more than the summation of the factory manager's individual plans.
I would caution that this account seems like it overstates the actual independence of the managers, no doubt there were many political restrictions on their freedom of action in practice, but the general account that the plan essentially comes from the low level managers seems sound.
According to Goodhart's Law, no. As he originally explained it: "Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes."
Metrics of GDP, inflation, and employment are commonly used in macroeconomics to approximate quality of life, but they're subject to the same problem. For instance, you may be able to increase GDP and employment by increasing violent criminality, expanding the markets for private security, insurance, weapons and prisons, but harming general quality of life.
The book Red Plenty gives an informative and compelling lightly fictionalized account:
https://slatestarcodex.com/2014/09/24/book-review-red-plenty...
Markets mostly work.
No. You can't set a metric and let the metric do your governing for you. There needs to be a human in the loop. In other words, the system has to be run by people who are making a good-faith effort to achieve the real objectives.
Markets partly solve the problem. You can have a market economy that optimizes the production of nails and other widgets according to the metric of profit, but if that's all you have, you will end up with corporations that produce lots of widgets at a huge profit, but in the process burn out workers, pollute the environment, and fill news channels with scandals about how Acme knew for the last thirty years that its products were poisoning consumers, but kept the truth hidden. So you need regulations to mitigate these problems. But this in turn requires that the regulators are acting in good faith instead of trying to game a metric. There always needs to be someone in the loop.
My favourite example of this was the introduction of the Microsoft Distributed File System (DFS) service into a customer environment. We were only using the DFS Namespaces feature, which is like DNS for file shares: the client downloads a blob of metadata and uses it to find an underlying file share for a logical name. The caching is very effective and the additional delay is negligible.
They had a file performance problem. So of course, they point the finger at the last thing that has changed in the environment: DFS! It must be DFS! I calmly point out that if the performance is bad after a connection has been made, it can't possibly be DFS, it's out of path after the initial negotiation. It's like blaming DNS for slow downloads. Makes no sense! But nope. They just won't accept that. It's the last thing that has changed!
I came back a week later to discover that instead of 2 redundant DFS servers, there are now 6 redundant DFS servers "for performance". To their surprise however, the file shares are still mysteriously behaving poorly.
They dragged me along to a meeting with a cast of thousands to discuss the issues. One guy spent most of the time arguing for increasing the number of DFS servers to 8, 10, or perhaps even more to solve the issue!
Meanwhile I'm having a side-conversation with the storage guy, who sheepishly admits that 3 out of 4 fibre channel paths were down, and this started at about the same time frame as the deployment of DFS. I point this fact out to the room. Everyone looks at me while blinking slowly. A few more moments of silence pass. Then someone helpfully suggests adding more CPU and RAM to the DFS servers. Maybe 8 processors and 64 GB will do the trick!
This is exactly like the boy looking for the coin under the light. It feels like it could be productive, versus definitely not being productive. It doesn't matter that logically it won't work, it's the feeling that matters.
An architect had decided we should build this as microservices, coupled by message queues. There was one microservice which split the file into records and parsed each one, one which validated each one, and one which handed off to the gateway.
In the first demo of the system, it took half an hour to process a file with a few thousand instructions in it. This was a ludicrous amount of time: it really should have been done in seconds.
The team met, and one of the senior developers pronounced the solution: since this was a microservice system, we would simply split one of the microservices in two, so we could scale out the amount of hardware we were using. The service selected was the first: rather than splitting and parsing the file in one pass, a first microservice would split the file into chunks, and pass each one onto a second microservice, which would parse them.
I asked where we thought the problem was, why we thought splitting a service would help, how we would measure the improvement, and, moreover, why we thought that adding a network hop would make things faster rather than slower. My questions were rejected as self-evidently unnecessary: it is well-known that you can improve the performance of a microservice system by scaling out.
The service was split. There was another demo. It was just as slow as before.
The project was removed from that team, and transferred to a new team under my leadership.
(this is a true story; the one fact omitted for the sake of drama is that the transfer of the project wasn't due to the embarrassing demo, it was purely down to staffing and logistics)
We don't have time to analyze entire chains so we make assumptions about chains that should be unbroken. Occasionally but inevitably we make wrong assumptions.
They do. They are humans, and humans have noses.
Using the statistical method decreases the chance that a wild guess by the sculptor ends up angering the Emperor and causing deaths in the village.
The story isn’t about the selection of outlier data points as being representative - its more about drawing conclusions through seemingly plausible sounding methods that are nevertheless completely disjoint from the thing you’re reasoning about.