1. Nobody really knows how to do it.
2. If you have a system for doing it, you're doing the computer's job.
(Sadly I cannot find the source of this quote.)
I don't think anyone argues with that. It's just that sometimes some of the biggest impostors hide behind "boundaries".
>>This will continue to be a problem for the next 100 years until we figure out the right way to make good software.
A lot of people figured it out already.. but those are a minority and the field is fueled continually with poorly instructed people. The Business can't distinguish quickly between these two categories and often it does not even bother (good interviewing is hard or expensive) because (in Europe) it's not the software efficiency or other quality making the profit.
You'll have to expand on this for me, because I find this claim shocking. Who figured it out, and what did they figure out?
I know big construction projects often suffer from similar problems, and they don't seem to have figured it out.
I find it quite strange that you are not aware about how much more reliable & secure is the product of the construction industry compared to software.
In software engineering, and in IT generally, there’s a fine line between following best practices and following a cargo cult.
When foo and bar both solve the job and equally fast, then yes. But in the example of the article the other version was much faster. So faster (assuming no bugs got introduced) means clearly the correct answer here.
Perhaps the existing socket-based solution simply used a bad timeout, and instead of a weekend of work to completely change the architecture of the system, it could have been fixed by changing one number in a configuration file. That would have been much lower risk, and not affected any other functionality, test suites, debugging practices, support procedures, etc.
Software is still a young field that celebrates youth, and single combat warriors, like "Mel". It reminds me of Tom Wolfe's "The Right Stuff", about the U.S. space program back in the 1950's. One person could and did go do crazy heroic things that helped a single flight succeed. Eventually, space flight grew up, and NASA today barely even mentions the names of their contributors and collaborators. They'd never put up with cowboys like that any more. That's not how you achieve successful, repeatable results in complex systems.
Or maybe I'm just getting old.
[1] "Naive" as in unaware of the ongoing office politics.
That's funny, your text reminded me of a colleague who discovered that the electrician she hired used the wrong cable..
In my experience, though, this is a much bigger problem in software because nobody really knows what they're doing. There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Correct Answer, so it becomes a political question.
When my electrician has a power supply over here and needs power delivered over there, we all know he's going to use wires, and he knows the right gauge to use. He's got a book somewhere with the answer, and there's a regulation somewhere that says what he's required to use. But I just trust him to use the right cable, because that's his specialty, and I've never seen him make something that was an order-of-magnitude worse than was required, or that I could do on my own.
Respecting boundaries is a lot easier when you can trust that other people are generally competent. This will continue to be a problem for the next 100 years until we figure out the right way to make good software.