4 ms·

I have seen "worse is better" trotted out many many times, used mostly as an appeal to authority instead of a clear instantiation of the argument presented in t

I have seen "worse is better" trotted out many many times, used mostly as an appeal to authority instead of a clear instantiation of the argument presented in the essay. I think this is because the argument in the original essay is not crisply presented (at least not to me). So authors take "worse" and "better" on some random dimension that's beneficial to them in the moment, and then appeal to the authority of this well respected essay to "prove" that their approach is better. This post is stating that they tried to generalize too much instead of building to narrow use cases first. There is no need to bring "worse is better" into it at all, IMO

CRConrad 4y ago
As I understand it, this all goes back to the original writings / theories / practices that "Worse is Better" was a reply to, which encouraged a "too theoretically pure" way of writing software: Everything abstracted away, generalised, (theoretically) infinitely flexible, etc -- at the cost of code complexity that in practice often turns out to be unnecessary for the vast majority of use cases. In that sense, every more or less radical simplification that sacrifices some of those fine (theoretical) advantages for simplicity can be said to be an example of "Worse is Better". Because what "Worse is Better" means is just that "theoretically 'worse', but much simpler code is actually better than theoretically 'better' but much more complex code". It's "worse" vs "better" on all those fine more or less theoretical dimensions against "worse" vs "better" on the single dimension of code complexity / simplicity. So I'd say this article, which was all about how a radical simplification of the code -- sacrificing the (unnecessary) generalization and flexibility they'd first tried to build into it -- turned out to bring a lot of other practical advantages, is a prime example of "Worse is Better". As I understand it.

CRConrad 4y ago

As I understand it, this all goes back to the original writings / theories / practices that "Worse is Better" was a reply to, which encouraged a "too theoretically pure" way of writing software: Everything abstracted away, generalised, (theoretically) infinitely flexible, etc -- at the cost of code complexity that in practice often turns out to be unnecessary for the vast majority of use cases. In that sense, every more or less radical simplification that sacrifices some of those fine (theoretical) advantages for simplicity can be said to be an example of "Worse is Better". Because what "Worse is Better" means is just that "theoretically 'worse', but much simpler code is actually better than theoretically 'better' but much more complex code". It's "worse" vs "better" on all those fine more or less theoretical dimensions against "worse" vs "better" on the single dimension of code complexity / simplicity. So I'd say this article, which was all about how a radical simplification of the code -- sacrificing the (unnecessary) generalization and flexibility they'd first tried to build into it -- turned out to bring a lot of other practical advantages, is a prime example of "Worse is Better". As I understand it.