I like the analogy, but it strikes me as missing the upside (and other potential causes of problems the author may be seeing).
Bisquick is a great solution if you have only one problem. I want more solutions like Bisquick: easy to map to the problem (pancakes -> Bisquick; not pancakes -> not Bisquick), hard to fuck up, low marginal cost above the inputs. It's great!
In the converse, we have lots of custom software solutions which are exorbitantly costly over the long term. Small companies without in-house expertise have to figure out how they will maintain software they depend on when their consultant (or the boss's nephew) leaves. Big companies with significant workloads and workforces can afford (and indeed, profit from: https://danluu.com/in-house/) high-complexity custom engineering, which is...fine...but even FAANG have trouble figuring out how to incentivize system maintenance and support.
At heart, I believe we haven't come to grips with the extreme disparity in capital costs vs unit costs of software, such that we don't really know how to pay for the unpredictable costs of bitrot and maintenance. As a result, every software development project is ultimately a question of "how are you going to pay for its ongoing support".
I think you're speaking to a different (but still legit) problem. The OP is asking about the nature of confusing complexity, as it might appear to a new programmer. The capital implications of making real, profitable software from interlocking systems of alchemy is indeed not a solved problem - but I would say that it's interesting point of alignment between capitalists and beginner software programmers! Everyone wants lower maintenance costs, in terms of both time and brainpower. The $500k+ FAANG superstar programmer is a byproduct of the fact that alchemy is much harder to master than chemistry.
> Everyone wants lower maintenance costs, in terms of both time and brainpower. The $500k+ FAANG superstar programmer is a byproduct of the fact that alchemy is much harder to master than chemistry.
I think I've lost the analogy here a bit, could you help me? I thought "alchemy" were general purpose systems meant to get you off the ground.
I'm nominally one of these "$500k+ FAANG superstars" (though I'm not actually a superstar) and nearly all of our engineering time is spent wrangling home-grown abstractions built specifically for our business needs, which don't feel like "alchemy" in this analogy. Certainly a few teams are more involved with AWS services, linux, and dev-tooling but that constitutes maybe 5% of the company.
Would you still describe this other 95% as "alchemy"? If so, why?
I would say that you've paid the opportunity cost of learning the interlocking systems that compose into your application, and the processes required to update, test, and deploy it. This composition occurs across various boundaries, inside and outside the process, the network, and so on.
The FAANG-ist is one that can pay that opportunity cost quickly and completely, such that they are able to reason about the system with confidence, particularly when it comes time to reverse a feature or bug request into a set of commits. Or, more likely, a set of experiments and commits based on the outcome of those experiments. Given that there is no unified language of application design, doing this requires detailed, specific knowledge of every sub-system involved, the abstractions their authors used, and the ability to translate between them such that you can imagine the entire causal change from input to output. This is hard, and it's why you make the big bucks. (Interestingly, I first wrote "bugs" instead of "bucks". :)
Bisquick is a great solution if you have only one problem. I want more solutions like Bisquick: easy to map to the problem (pancakes -> Bisquick; not pancakes -> not Bisquick), hard to fuck up, low marginal cost above the inputs. It's great!
In the converse, we have lots of custom software solutions which are exorbitantly costly over the long term. Small companies without in-house expertise have to figure out how they will maintain software they depend on when their consultant (or the boss's nephew) leaves. Big companies with significant workloads and workforces can afford (and indeed, profit from: https://danluu.com/in-house/) high-complexity custom engineering, which is...fine...but even FAANG have trouble figuring out how to incentivize system maintenance and support.
At heart, I believe we haven't come to grips with the extreme disparity in capital costs vs unit costs of software, such that we don't really know how to pay for the unpredictable costs of bitrot and maintenance. As a result, every software development project is ultimately a question of "how are you going to pay for its ongoing support".