Hacker News Reader

I think there's a lot of truth to this. It reminds me of an idea in economics about the "second-best". From the wikipedia page:

"In welfare economics, the theory of the second best concerns the situation when one or more optimality conditions cannot be satisfied. The economists Richard Lipsey and Kelvin Lancaster showed in 1956 that if one optimality condition in an economic model cannot be satisfied, it is possible that the next-best solution involves changing other variables away from the values that would otherwise be optimal. Politically, the theory implies that if it is infeasible to remove a particular market distortion, introducing one or more additional market distortions in an interdependent market may partially counteract the first, and lead to a more efficient outcome."

https://en.wikipedia.org/wiki/Theory_of_the_second_best

I hate intervention but I like analysis. Good insights there, I did not know about this theory.

That worse-is-better is self-reinforcing and that it's the only stable strategy in an environment with less-than-perfect cooperation (i.e. it's the only Nash equilibrium) may both be true at the same time. In fact, if the latter is true then the former is alsmost certainly true.

The real question is, then, whether doing "the right thing" is a stable and winning strategy at all, i.e. viable and affordable. As you yourself suspect, the answer may well be no. Not only because it takes a few tries to figure out the right foundations, but also because what foundation is right is likely to change over time as conditions change (e.g. hardware architecture changes, programming practices -- such as the use of AI assistants -- change etc.).

> the worse is better approach is better.

I think this ties back to the idea of "get it working, then once it's working go back and make it fast | preformant | better for whatever meaning of better".

I think much of the consternation towards "worse is better" comes from re-inventing things to achieve the "make it better" improvements from scratch instead of leveraging existing knowledge. Re-inventing might be fine, but we shouldn't throw away knowledge and establshed techniques if we can avoid it.

That may be one failure mode, but another one is more prominent: Half-assing the next feature is more interesting than going back and making the last feature that you half-implemented actually work. That goes for both commercial and open-source software.

I have a question for this premise.

How would you design a network interface using your right foundations model? I'm not talking about HTML or whatnot.

I have some sort of medium, copper, fiber whatever and I would like to send 10 bytes to the other side of it. What is the right foundations that would lead to an implementation which isn't overly complex.

Not a direct answer, but Ethernet is sometimes brought up as a successful example of Worse is Better. At one point Token Ring was a serious competitor - it had careful designs to avoid collisions when the network was busy, prioritize traffic, etc. But it was comparatively slow and expensive. Ethernet just says "eh, retry on collision.". And that simplistic foundation has carried on to where we have a standard for 800 Gigabit Ethernet.

Since speed and expense are relatively important and collisions are relatively rare, this sounds more like "better is better".

Unfortunately, I am not a network engineer. So I don't know how I would approach this problem other than to try to make sure that the resulting hardware is easy to deal with from firmware and software.

I have worked with hardware directly and there is something inherently simple about some hardware APIs versus others.

What's more, the complexity doesn't entirely relate to the underlying hardware or protocol complexity.

The issue is, though, that reality is complicated. This is where the right foundations are important. It's not necessarily that the right foundations themselves have simple internals, but that the right foundations successfully tame the complexity of reality.

The best place to work on developing the right foundations is therefore precisely at such interfaces between the real world and the software world.

> I have some sort of medium, copper, fiber whatever and I would like to send 10 bytes to the other side of it. What is the right foundations that would lead to an implementation which isn't overly complex.

The bane of every project is understanding what you actually need to do

For example, it is entirely possible that the "right foundation" for your proposed scenario is: Hook one end up to a lightswitch, the other to a light bulb, hire two operators trained in morse code. Then once the 10 bytes are sent write them their cheques and shut it down.

Telegraph/morse code would probably work fine.

For this application I might also consider classic serial/RS-232 (c. 1969), which can be implemented with one signal wire (tx) and can connect to modern USB.

I'm not entirely sure whether they qualify as "right foundation" but they've worked well in practice.

> But the difficulty of "the right foundations" is that nobody knows what the right foundations are the first 10 times they implement them

Yes and it worse than that. The right foundations might change with time and changing requirements.

good comment. But I question how much you can package up inherent complexity in a simple interface, due to leaky abstraction.

The biggest benefit of simplicity in design is when the whole system is simple, so it’s easy to hack on and reason about.

Abstraction leaks are usually a result of a worse is better approach. But yes, as I think I said in my original comment, its very difficult to successfully completely pave over a poor base.

And yes, I agree that simplicity needs to start quite low down the stack (ideally at the hardware, or the firmware, or the drivers, or the kernel as a last resort) for the complexity not to explode as you keep adding layers.