This analogy does not work. He's trying to make the point that we don't know what caused PayPal's application to speed-up and Node.js may not be the root cause at all. The cheese analogy is not correct since he's claiming their benchmark is like the orange color - a false proxy for what you really want: good tasting cheese. You do really want your application to go faster, though. It's not a false proxy - it's what this team was optimizing for. They had a measurable increase in success - they made better cheese.
> He's trying to make the point that we don't know what caused PayPal's application to speed-up and Node.js may not be the root cause at all. The cheese analogy is not correct since he's claiming their benchmark is like the orange color - a false proxy for what you really want: good tasting cheese.
I think you've misunderstood the analogy.
He's claiming that without knowledge of the prior state of their systems and the differences (besides implementation language) between the Node.js and earlier implementation that underlies the benchmark, "using Node.js" may be analogous to the orange color in the cheese -- something that came along with the cause of the improvement that is not actually the source of the improvement -- and that splashing Node.js on other applications (as in PayPal's stated decision based on the result of this upgrade to use Node.js on all future consumer-facing applications, but more importantly other people using PayPal's experience to justify using Node.js for their applications) may be analogous to dyeing the cheese.
> They had a measurable increase in success - they made better cheese.
Right. He's saying that "PayPal made a faster web app. They used Node.js. Therefore, we should use Node.js if we want our web apps to go faster" may be analogous to "Farmer Bob's cheese is better tasting. His cheese is orange. Therefore we should buy orange cheese if we want better tasting."
Though, really, like most uses of colorful analogies to get points across in technical articles it does a lot more to obscure the point than to illustrate it.
The TL,DR: You are taking a significant risk of serious error when you accept a claim that a change that preceded an effect caused that effect when you don't know what other changes occurred at the same time that may be relevant to the effect under consideration.
There are two blog posts here, both interesting, but not deeply connected. One is about false proxies, which is specifically about people manipulating perceptions.
The other is about getting "measurably better cheese" but not understanding why it's measurably better. Speed is not a proxy for speed, it's just speed. The meme here is that correlation does not equal causation.
> The point is speed is a false proxy for the quality of Node.js.
Well, no, speed is the actual measure of interest. The point is that reimplementations that change language also often change other design features, and that without knowing what else changed one cannot validate the attribution of the post-change speed improvement to Node.js.
