There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency in order to create a bigger global efficiency. That's life.
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.
That's an interesting perspective. I think you're right that we don't have "correct" and standard answers because we don't assume total competency, but I think we don't assume total competency because software development (both the requirements and the practices) change fairly rapidly. I wouldn't be surprised if in 100 years, we're still trying to figure out standards, if the pace keeps up.
>>There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency..
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.
Individual "masters craftsmen" have always figured out things like this way before they have become common practice. But I think original poster was meaning "we" as a profession stabilizing on standard good practices that everyone knows and uses, not just a few masters.
Software is not the first industry to deal with systems complexity or large teams management but (in my part of the world at least) it's the first to expect engineering-like results from non-engineering workers and managers. There are developers who have noticed the similarities between creating/assembling/testing components & modules in other industries and software and borrowed practices before software had a name for them. It's just that these people are dispersed in a sea of devs tuned to Microsoft Framework Factory or busy building castles on Javascript Frameworks Sands.
" 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 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.
That's not clear at all to me. This system sounds extremely complex (which could be one of the causes of the problem!), so I don't see how we can assume that no bugs got introduced, nor that execution speed is the only metric that matters.
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.
I don't think the single combat warrior is the right analogy for the article. Instead, to me it felt more like a "The Emperor's New Clothes" kind of situation, in which a naive [1] youngster inadvertently exposed the dysfunction of the organisation. Judging by the author's description, nothing that could have solved the performance problem – not even a simple config parameter – would have gone over well in the war between the two factions.
[1] "Naive" as in unaware of the ongoing office politics.
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.