This looks like reframing software performance as a commons problem - individual companies want to save their time and externalize inefficient software, and collectively everyone ends up using everyone else's inefficient software. At the same time, if a company's programmers end up wasting a lot of time waiting on a specific type of software, there's now a market for a higher end implementation of that type of software, which makes me wonder why no one takes the other end of that bet.
Or, if two companies make each other inefficient enough, they could strike an agreement to improve the relevant pieces of their software, which should be mutually beneficial if the post's point holds (and their software is actually possible to change)
I am inclined to agree with Ryan's perspective here, and like you, I also wonder why so few seem to think of the "missing" efficiency as an ocean of opportunity space.
I don't know enough to answer it thoroughly, but I have encountered some likely factors:
1. There seems to be proportionally less programmers who know how to write efficient software over time. Finding a qualified team can be hard, and if the company culture doesn't discourage inefficiency, the common and less qualified team members will likely propagate severe unnecessary complications and inefficiencies over time.
2. It seems to inherently take a lot of experience to comprehend large flows of data in software, and it seems most common to initially comprehend very limited scopes, like individual elements - which is inherently inefficient to work with, because it both adds unnecessary complexity and goes against the fact that modern hardware is most efficient when batching all the compute required on a data set, before moving on to different data.
3. The demand for general software seems much higher than the supply of programmers. Which means misguided company strategies still thrive. And additionally, the value that computers can add per programmer is so massive that the tolerance for bad practices can be very large. One programmer can write software in a short timespan, that is executed trillions of times over its existence, which is extremely disproportional to how productive and cost-efficient humans would be at executing the "programmed" tasks over time. Hardware is fairly cheap compared to humans, and electricity too.
4. Programmers are not proportionally rewarded for their value added over time, nor deducted for the propagating inefficiencies. Additionally, so much software is both free and open source, and I think this may contribute to less value perceived from hiring, being or becoming a performance-aware programmer.
5. It requires a very (seemingly rare) logical mindset to reason about performance of things that take less than 10ms. And comparing the human time scale with a computer's time scale. It's already hard for many (most?) people to comprehend what a million really is. And a modern computer can do trillions of math ops in the time it takes for us to blink. Differentiating between trillions and billions is not very naturally intuitive for humans.
6. The dogma is so massive, deep and entangled that the rebellious risk-tolerant people inclined to take such challenges on may not easily realize just how much opportunity space is there.
7. The personalized echo chambers of the modern Internet may be contributing negatively to inclinations to subvert dogmas.
But I do think the tides could be changing. And I think it has to eventually.
There's also something to be said about the common inclination to do slow generalized software rather than efficient specialized software. On the surface level, you can provide more value with generalized software, but in my experience it's less commonly understood that much generalized software sucks to actually use (and is typically inefficient). And error handling can quickly become a huge part of the software (including maintenance) if it takes on responsibilities of an overwhelmingly large scope of problems.
And another part is inheriting flaws in existing systems. Like how Exceptions are a built into many programming languages and it's not intuitive just how much they disturb control flow and introduce scope paranoia if you've never tried to work without them. To break free from dogmas I think you need to be good at reasoning from fundamentals, and finding ways to experiment with different ways to do things. E.g. through discourse and/or tinkering.
Additionally, I also think it's relevant that the sunk cost fallacy is thriving among programmers. Many of the tech giants have entire ecosystems hooking large amounts of programmers and companies into using their bad software, because they'd be losing a lot of features and clients if they quit. This is also called high "switching cost" and is a common deliberate strategy to keep customers from choosing better alternatives. There's a lot of marketing and psychology strategies going on to preserve the status quo.
But I'm always very open to hear how other experienced programmers see these issues. I feel like I still have a lot to learn and definitely don't have a handle on how the software industry works as a whole, or why it is the way it is.
So instead of agreeing that SOLID principles are valuable indeed and clarifying that the definition of clean (or Clean if you will) code should always be perceived in context of software requirements, including speed and efficiency, we're just dismantling the work of Dr. Marting and declaring it untrustworthy, outdated, irrelevant, and so forth?
The fact that some software is slow by design has nothing (or very little) to do with clean code. Some programmers just cant write good (fast, efficient) algorithms l. There is no conflict per se. It's a problem context.
"I need file system explorer, fast" and "I need fast file explorer" are two different problems. Both can be executed with clean code.
This looks like reframing software performance as a commons problem - individual companies want to save their time and externalize inefficient software, and collectively everyone ends up using everyone else's inefficient software. At the same time, if a company's programmers end up wasting a lot of time waiting on a specific type of software, there's now a market for a higher end implementation of that type of software, which makes me wonder why no one takes the other end of that bet.
Or, if two companies make each other inefficient enough, they could strike an agreement to improve the relevant pieces of their software, which should be mutually beneficial if the post's point holds (and their software is actually possible to change)
I am inclined to agree with Ryan's perspective here, and like you, I also wonder why so few seem to think of the "missing" efficiency as an ocean of opportunity space.
I don't know enough to answer it thoroughly, but I have encountered some likely factors:
1. There seems to be proportionally less programmers who know how to write efficient software over time. Finding a qualified team can be hard, and if the company culture doesn't discourage inefficiency, the common and less qualified team members will likely propagate severe unnecessary complications and inefficiencies over time.
2. It seems to inherently take a lot of experience to comprehend large flows of data in software, and it seems most common to initially comprehend very limited scopes, like individual elements - which is inherently inefficient to work with, because it both adds unnecessary complexity and goes against the fact that modern hardware is most efficient when batching all the compute required on a data set, before moving on to different data.
3. The demand for general software seems much higher than the supply of programmers. Which means misguided company strategies still thrive. And additionally, the value that computers can add per programmer is so massive that the tolerance for bad practices can be very large. One programmer can write software in a short timespan, that is executed trillions of times over its existence, which is extremely disproportional to how productive and cost-efficient humans would be at executing the "programmed" tasks over time. Hardware is fairly cheap compared to humans, and electricity too.
4. Programmers are not proportionally rewarded for their value added over time, nor deducted for the propagating inefficiencies. Additionally, so much software is both free and open source, and I think this may contribute to less value perceived from hiring, being or becoming a performance-aware programmer.
5. It requires a very (seemingly rare) logical mindset to reason about performance of things that take less than 10ms. And comparing the human time scale with a computer's time scale. It's already hard for many (most?) people to comprehend what a million really is. And a modern computer can do trillions of math ops in the time it takes for us to blink. Differentiating between trillions and billions is not very naturally intuitive for humans.
6. The dogma is so massive, deep and entangled that the rebellious risk-tolerant people inclined to take such challenges on may not easily realize just how much opportunity space is there.
7. The personalized echo chambers of the modern Internet may be contributing negatively to inclinations to subvert dogmas.
But I do think the tides could be changing. And I think it has to eventually.
There's also something to be said about the common inclination to do slow generalized software rather than efficient specialized software. On the surface level, you can provide more value with generalized software, but in my experience it's less commonly understood that much generalized software sucks to actually use (and is typically inefficient). And error handling can quickly become a huge part of the software (including maintenance) if it takes on responsibilities of an overwhelmingly large scope of problems.
And another part is inheriting flaws in existing systems. Like how Exceptions are a built into many programming languages and it's not intuitive just how much they disturb control flow and introduce scope paranoia if you've never tried to work without them. To break free from dogmas I think you need to be good at reasoning from fundamentals, and finding ways to experiment with different ways to do things. E.g. through discourse and/or tinkering.
Additionally, I also think it's relevant that the sunk cost fallacy is thriving among programmers. Many of the tech giants have entire ecosystems hooking large amounts of programmers and companies into using their bad software, because they'd be losing a lot of features and clients if they quit. This is also called high "switching cost" and is a common deliberate strategy to keep customers from choosing better alternatives. There's a lot of marketing and psychology strategies going on to preserve the status quo.
But I'm always very open to hear how other experienced programmers see these issues. I feel like I still have a lot to learn and definitely don't have a handle on how the software industry works as a whole, or why it is the way it is.
So instead of agreeing that SOLID principles are valuable indeed and clarifying that the definition of clean (or Clean if you will) code should always be perceived in context of software requirements, including speed and efficiency, we're just dismantling the work of Dr. Marting and declaring it untrustworthy, outdated, irrelevant, and so forth?
The fact that some software is slow by design has nothing (or very little) to do with clean code. Some programmers just cant write good (fast, efficient) algorithms l. There is no conflict per se. It's a problem context.
"I need file system explorer, fast" and "I need fast file explorer" are two different problems. Both can be executed with clean code.
> we're just dismantling the work of Dr. Marting and declaring it untrustworthy, outdated, irrelevant, and so forth
Yes.