back
169 comments
This is a really important concept for developers.

One aspect for developers that I see quite often is the assertion that "We can't have X without giving up more Y", most commonly "we can't have more security without giving up on user experience". With the Pareto idea in mind, we can see that that statement is true, if and only if you are in fact on the Pareto frontier of security and user experience already.

However, many times these confident pronouncements are being made when the system under question is quite evidently not on the Pareto frontier in the first place and indeed you can get more of one without giving up the other.

Making it more tricky is that in business, you can never discard "money" as a dimension, so unless you're taking "money" as one of the dimensions in the original comparison you want to do, it sneaks its way in. Or, a composite time/money, or "cost to business", or some other similar concept, time & money aren't orthogonal and don't need to be treated as two separate dimensions in general, though you can if you want. Which puts you into the 3D case, and as the page says, that grows the frontier quite a lot, which is good in some ways and bad in others. Nevertheless, in my opinion it is still often the case that even in that space we are often making "tradeoffs" without checking that we're on the Pareto frontier in the first place.

Agreed with what you said, when you're only considering security and usability you're often not at a Pareto optimal state, but once you add cost into the picture you see a lot more cases of being on the Pareto optimal boundary, or at least in case where the next improvement only comes with significant effort (by re-platforming, for example).
Yes, the difference between coding (writing software) and engineering (making informed trade offs about system design) is effectively bound up in analyses like those supported by concepts like pareto efficiency.

One should keep in mind though that not all problems have a neat solution. Many spaces have multiple efficient points that still need to be chosen from, and many pareto optimization problems actually become NP hard computationally when the problem is large enough.

"making tradeoffs" is an excuse for management to cut corners to get their feature faster at the cost of future developer pain and suffering

you know how japanese oni would roll human souls into soba noodles? [1]

that's what modern corporate software company management does :)

[1] i learned about this from the very funny gintama funeral episode

there's something equivalent in the business world - mostly used by businesses not run by psychopaths - where you optimize inside 2 triangles with the points on the triangle being cost, profit, & user utility/happiness.
this is a silly oversimplification
I did similar analysis a couple years ago for optimizing item builds in WoW classic. The tricky part in WoW is that there are 15ish item slots with hundreds of item choices for each slot, so the total number of builds is well over 100^15.

I ended up using a divide-and-conquer style approach, where I 1) pruned items that weren't on the Pareto frontier individually for each slot, 2) took the two slots X and Y that had the least items after pruning and grouped them by calculating Z:={x+y|x∈X,y∈Y}, 3) pruned items that weren't on the Pareto frontier in Z, and 4) repeated steps 2-3 until there was only one group remaining, comprised of the full Pareto-optimal item builds.

This ran in a couple of seconds, as opposed to the other solutions I tried that took somewhere between minutes and years. The downside was that including set bonuses into the model took extra work.

Fascinating! Do you still have any of the code or datasets/datasources laying around?
I did not understand https://news.ycombinator.com/item?id=49096439, but I understood this.
I am the complete opposite of that. My attention wanes when someone fails to get to the point, instead dwelling in irrelevant details which are not intrinsically interesting. Have to muster the motivation to concentrate in such circumstances, and doing so is not enjoyable.
But Wikipedia tells you in the first paragraph what it's all about.

A "Pareto front represents the set of solutions where no solution outperforms any other solution in the set at every objective, and every solution not in the set is outperformed by at least one solution in the Pareto front in every objective"

> You probably won't pick a driver sitting on the edge of the frontier because you want some balance between speed and acceleration

for super mario kart speedruns go with bowser/dk: https://www.speedrun.com/smk/runs/zp68nr8m

That seemed to hold up for Mario Kart 8 too going with Bowser at the edge of their pareto frontier, https://www.speedrun.com/mk8

needing acceleration is a skill issue

There are a few things that are assumed to be true when talking about the Pareto frontier here, but aren’t always true.

One, that more of something is always better, e.g. it is always better to have more speed.

Maybe, but what if having too much speed causes you to run off the track and perform worse? It could be that there is actually a peak in the utility of speed that declines as it increases.

There could also be important relations between attributes that make determining a Pareto frontier impossible or at least more difficult. For example, some pairs of attributes work best when they are a specific ratio, and increasing one or the other will actually decrease utility unless the other is increased at the same time.

Of course I, and most of the dads I know, optimise for something else: what’s the car that will keep me competitive, but probably losing, to the kids?
Previous discussion (2024): https://news.ycombinator.com/item?id=39936246
I love when people do an amazing job carefully explaining something complicated in a way that makes it seem very intuitive. Excellent job. Way to show off those technical communication chops!
Ive been played. Me and my brother used to play this all the time. He would always beat me and whenever I would win it would be a momentous occasion. Turns out his build was directly on the pareto frontier and mine was not even close. Damn you brother. Hes totally screwed next time we play
I would really love to be able to explore this data, e.g. what is the "worst" driver? Is there an inverse Pareto front?
On a tangent, I was a bit confused by the everyday examples given in this article.

"We're often faced with similar trade-offs. You want a meal that's both cheap and delicious? A job that's both well-paid, easy, and fulfilling?"

I really don't feel like "easy" is a dimension I wish to optimize for in a job. It almost feels opposite to what I've actually optimized for - since for me a fulfilling job usually means full of deep technical challenges. I want a job without unnecessary friction, without interpersonal drama, even one that's low stress. But definitely not easy.

If you liked the playing card interaction at the start (I did), I run a random side project where you (or your coding agent) can build similar 3d cards:

https://requirement5.com

build a card here: https://requirement5.com/create (and the CLI instructions are there too)

https://github.com/vilt9/requirement5

This doesn't account for vehicle size (important for red shell wall breaking[0]) and drifting style[1].

[0] A redshell wall break is when you point your vehicle near a wall to break a redshell without using a defense item. [1] Drifting style is either inward or outward. Inward drift has more intuitive controlls and is way better for intermidiate players, but pro players dislike it because is removes various difficult tricks.

I recommend yoshi on the yoshi bike with azure rollers and the paper glider.

I used to play Diddy Kong Racing for the Nintento 64 a lot and what I learned is that the smaller carts with fast acceleration were good for learning how to navigate around the course and for battle royal, but the heavier drivers like Banjo had the highest top speed, and I developed better steering capabilities to time each curve, eventually making it sometimes the only way to win the race.
Once I was told to upgrade tls to 1.2 (latest version at the time) due to some compliance thing or other. So I did. Then I noticed something. The user never provided any certificates themselves. I asked why. "Because it would be bad ux". I went looking and lo and behold, there it was, the first line in Main():

    ServicePointManager
        .ServerCertificateValidationCallback += 
        (sender, cert, chain, sslPolicyErrors) => true;
But it was using TLS1.2!
Apologies for the self-promotion, but I learned about the Pareto Front from this site a while back - and applied it to Mini PCs with https://minipcs.zip which plots Mini PCs based on Compute vs Price (and other metrics) - highlighting the pareto front to find the optimal unit.
I love how the data from top players shows that they're using a build on the Pareto Front, i.e. that the wisdom of crowds settles on a meta that is optimum. I wonder if we analyzed other games, if the meta were all consistently on the Pareto Front (WoW, Diablo, w/e). Likely so.
This article isn’t quite accurate; acceleration is surprisingly unimportant in Mario Kart and not really considered a major factor when choosing a optimal combo. The optimal combo is solely decided on the basis of speed and mini-turbo. Otherwise good analysis.
Can anyone explain why Rosalina is not Pareto optimal here? It kind of looks like she should be.
Excellent. This is some kind of 3D PowerPoint. How did he do that?
So Pareto’s the third brother then?
> You can identify all efficient drivers that, unlike Koopa, are never dominated on both speed and acceleration. Together, they form what is called the Pareto front (or frontier).

Coincidently, this Pareto Front concept is currently on the front page on HN at #10 (https://news.ycombinator.com/item?id=49096439) and apparently, it was posted before this post.

https://news.ycombinator.com/item?id=39936246 for the discussion 2 years ago
I did not know the term but I'm thinking that the old project management triangle (cheap, good, fast) is a specialisation of that concept.
Nice article, I'm sad to learn that I shouldn't be using Koopa. How are Peach and Mario not dominated on acceleration by Tanooki Mario and Luigi respectively?

Also, wonderful visualizations, but the change between blue and white backgrounds is really jarring to me.

What I've found is that my favorite person is not optimal... I have decided that I'm going to believe that the driver is worth more than the sum of their choices. And when I lose I'll just accept it as my own failing of skill. #rosalina
A lot of these optimization problems can benefit from using a genetic algorithm: https://github.com/lodenrogue/genetic-algorithm-js
I always thought in these games; picking acceleration is a way for you to recover from your mistakes. If you made no mistakes the speed would win. So, it is always better to pick the harder option and have a room to improve
Previously on HN: https://news.ycombinator.com/item?id=39936246
80/20 Rule in Mario Games - https://8020.in/mario-games
I didn't know that even characters of similar size had different stats
Finally, this page has some information that's actually useful in real life.
To think I gimped myself so much by using baby Rosalina on a scooter with rollers
Holy! This is one of the best articles i ever read here. Really, really cool.
Finally an important and realistic application of economic theory to real life!
Thanks! Very useful information. I will never play for Bowser again.