Validation that a PCB was manufactured correctly is... easy. Disagree, but how about VLSI. It's hugely automated. Moore's Law is exponential but team sizes aren't. That productivity gap is made up for with huge amounts of automation. And nothing is easy about manufacturing validation of an ASIC.
I do think one primary difference between physical objects and software is we bother to have precise specifications that one can validate against, and I think that's what you're trying to get at. If all software had that then software could have an "easy" validation story too, I suppose.
I have mixed feelings about precise specifications in software. On the one hand the hardware engineer in me thinks everything should have an exact specification. On the other hand, that's throws away the "soft" advantage which is important for some types of software. So there is a spectrum.
FWIW I don't think there's anything factually wrong with what you said, but I think misses the parent's point. They would be incredibly naïve to say that hardware is easy. But I think they were using "easy" as a relative word, not absolute. As is natural in these conversations, but also easily leads to misunderstanding.
> I do think one primary difference between physical objects and software is we bother to have precise specifications that one can validate against
Having been on the hardware side and now on software (specifically ML) this is one of the biggest differences I've noticed. It's a lot harder to validate programs. But I think the part that concerns me more is the blasé or even defensive attitude. In physical engineering it often felt "it's the best we can do for now" with people often talking about ideas and trying to make it work. It seemed of concern to management too. But in software it feels a lot more like "it gives the right output" and "it passes the test cases" (hit test cases aren't always robust and don't have the same guarantees as in physical design) and call it done. The whole notion of Test Driven Development even seems absurd. Tests are a critical part of the process, but to drive the process is absurd. It just seems people are more concerned with speed than velocity. A lack of depth, and I even frequently see denial of depth. In physical it seems like we're always trying to go deeper. In software it seems like we're always trying to go wider.
This isn't to say that's the case everywhere, but it is frequent enough. There's plenty of bad physical engineering teams and plenty of great software teams. But there's definitely differences in approaches and importantly differences in thresholds. The culture too. I've never had a physical engineer ask me "what's the value?", clarifying that they mean monetary value. I've had managers do that, but not fellow engineers. The divide between the engineering teams and business teams was clearer. Which I think is a good thing. Engineers sacrifice profit for product. Business sacrifices product for profit. The adversarial nature keeps balance
I do think one primary difference between physical objects and software is we bother to have precise specifications that one can validate against, and I think that's what you're trying to get at. If all software had that then software could have an "easy" validation story too, I suppose.
I have mixed feelings about precise specifications in software. On the one hand the hardware engineer in me thinks everything should have an exact specification. On the other hand, that's throws away the "soft" advantage which is important for some types of software. So there is a spectrum.