← Back to context

Comment by AlotOfReading

1 hour ago

It's notable how many more engineers are paying attention to the details in mechanical systems. Take a random electrical connector in your car. Likely dozens of engineers were involved in its design and manufacturing. Dozens were involved with incorporating it into the vehicle design and installing it during manufacturing. There are entire teams who specialize in e.g. high-vacuum flange seal design. It's pretty rare to find similar teams in software.

I will argue that mechanical systems are fundamentally simpler than software, though. Try writing a datasheet for some library as an exercise. Thoroughly documenting the interface is tedious, but straightforward. You need graphs though, so maybe performance under load? But that's assuming a lot about hardware and runtimes, so you need to characterize it under all of those possible degrees of freedom. That's a much larger space than physical components have. Imagine characterizing/qualifying parts under disparate manufacturing methods that include "some sleep-deprived rando who's never heard of a lathe needs to build this successfully in his garage" (i.e. the norm in OSS).

And even if you successfully write a datasheet, some unrelated component elsewhere in the system can remotely interfere with your software through chained vulnerabilities, memory pressure, contention, etc. Mechanical engineers rarely worry about entirely disconnected parts interfering in undocumented ways, because reality limits how things can interact. RF engineers consider this kind of problem more regularly, and need correspondingly more animal sacrifices. The larger the software the worse this problem becomes, and small software systems are increasingly endangered these days.