5 ms·

You are experiencing what I call "The Bisquick Problem". Bisquick is basically flour with some other stuff, like salt, premixed into it, and sold in a box in th

You are experiencing what I call "The Bisquick Problem". Bisquick is basically flour with some other stuff, like salt, premixed into it, and sold in a box in the USA. So instead of just buying flour and salt, you buy them together, which makes some things easier (like making pancakes), but it complicates literally everything else. You can't use it as flour, or as salt. With software, the problem is even greater. You can use react, for example, but you will probably start with create-react-app, which adds a lot of things. Or you could start with Next.js, which adds a lot of things. You could use Java, but you will probably start with Spring Boot, or Dropwizard, which adds a LOT of things. Plus all of these starting points imply the use of new languages, configurations, and programs, in particular, builds. In my view, all of these "Bisquicks" represent experiments-in-progress, with the ultimate goal of the systematic characterization of "software application", in general. In other words, they are systems of alchemy, pushing toward being a system of chemistry, which we don't have yet. So it is bound to be a confusing time, just as it was surely confusing to play with chemicals before Lavoisier systematized the practice.

pohl 5y ago
As someone who grew up in a house that was never without a box of Bisquick in the cupboard, that phrase speaks to me.
RiyaadhABR 5y ago
This is a very helpful view on things. It definitely seems like evolution is taking place. Many of the new solutions are a mixture of other solutions with a certain aspect being the most important. NextJs, Remix, RedwoodJs are all its own solution in adding what the creators feel are missing from React in terms of server side functionality. Eventually there will be a clearer picture of which tool to use for various tasks like internal tools, eCommerce, B2B or cross platform applications.
- jrumbut 5y ago
  The problem usually isn't the next layer of abstraction. NextJs and Remix are just fine (I don't have experience with RedwoodJs). The issue is that developers tend to put "Here be dragons!" in their mental map of whatever is two levels down the abstraction chain from where they live. When those layers are small additions, people end up not understanding (or even fearing) components of their stack that are quite close to the surface. It's hard to do quality software engineering when you can't reason about the foundation of what you're building. But if you lived through the process of adding new layers or if you take the time to learn more layers of your stack, you'll be able to make the most of the tradeoffs inherent to adding the latest framework or library.
- chillacy 5y ago
  They say the only two ways in business to make money are bundling and unbundling. This is surprisingly applicable to software frameworks as well.
md_ 5y ago
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/ 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".
- javajosh 5y ago
  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.
  - Hermitian909 5y ago
    > 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?
Wilem82 5y ago
> Plus all of these starting points imply the use of new languages, configurations, and programs, in particular, builds. Oh yeah, true, some people keep saying a language is just a tool trying to convince somebody to use it, but they forget, or omit for some reason, the fact that it's not "just a tool", it's a huge ecosystem that brings additional, enormous mental burden with it - build system(s), libraries popular within that specific ecosystem, language syntax, language quirks, project structure, its own conventions and so forth. It's much simpler and more efficient (technically and labour market-wise) to write everything in a single language, as much as possible - unless you start going completely against the grain. Like, auxilliary scripts are usually written in cli-centric languages like Bash, as opposed to API-centric like Python, because you get maximum convenience using cli programs and composing them together. But no, some people casually shoot themselves in the foot by jumping from language to language depending on the task because it's "just a tool". Ripgrep is a just tool. An entire programming language with its ecosystem is not.

pohl 5y ago

As someone who grew up in a house that was never without a box of Bisquick in the cupboard, that phrase speaks to me.

RiyaadhABR 5y ago

This is a very helpful view on things. It definitely seems like evolution is taking place. Many of the new solutions are a mixture of other solutions with a certain aspect being the most important. NextJs, Remix, RedwoodJs are all its own solution in adding what the creators feel are missing from React in terms of server side functionality. Eventually there will be a clearer picture of which tool to use for various tasks like internal tools, eCommerce, B2B or cross platform applications.

jrumbut 5y ago
The problem usually isn't the next layer of abstraction. NextJs and Remix are just fine (I don't have experience with RedwoodJs). The issue is that developers tend to put "Here be dragons!" in their mental map of whatever is two levels down the abstraction chain from where they live. When those layers are small additions, people end up not understanding (or even fearing) components of their stack that are quite close to the surface. It's hard to do quality software engineering when you can't reason about the foundation of what you're building. But if you lived through the process of adding new layers or if you take the time to learn more layers of your stack, you'll be able to make the most of the tradeoffs inherent to adding the latest framework or library.
chillacy 5y ago
They say the only two ways in business to make money are bundling and unbundling. This is surprisingly applicable to software frameworks as well.

md_ 5y ago

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/ 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".

javajosh 5y ago
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.
- Hermitian909 5y ago
  > 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?

Wilem82 5y ago

> Plus all of these starting points imply the use of new languages, configurations, and programs, in particular, builds. Oh yeah, true, some people keep saying a language is just a tool trying to convince somebody to use it, but they forget, or omit for some reason, the fact that it's not "just a tool", it's a huge ecosystem that brings additional, enormous mental burden with it - build system(s), libraries popular within that specific ecosystem, language syntax, language quirks, project structure, its own conventions and so forth. It's much simpler and more efficient (technically and labour market-wise) to write everything in a single language, as much as possible - unless you start going completely against the grain. Like, auxilliary scripts are usually written in cli-centric languages like Bash, as opposed to API-centric like Python, because you get maximum convenience using cli programs and composing them together. But no, some people casually shoot themselves in the foot by jumping from language to language depending on the task because it's "just a tool". Ripgrep is a just tool. An entire programming language with its ecosystem is not.