A different angle: I think a lot of software is not accessible due to friction points and interfaces. Non-compatible interfaces, and simply being proprietary for business/incentive reasons.
So, you might ask "Why are you building X when Y exists". The answer is usually something to the effect of "I can't interface with Y". Programming languages themselves are one of these obstacle. So is linking to system libraries. (e.g. many C and C++ code bases) C-FFI sometimes makes this easier though.
I value low-friction interfaces in software, and I think this is usually not done well.
Another example: I think this is why I dislike Async rust so much. It places a barrier within the language.
Some concrete anecdotes from the past few days: Why am I writing SPME algorithms, asking an LLM to implement a linear constraint solver, etc? Those and many more algorithms that have existed and been heavily used for decades? No/shitty rust libs, and the C/C++ libs have no good way I can interface with, aren't documented well, license concerns etc. I.e., I could try to re-use, but instead re-write because it's, surprisingly, the lower-friction option.
People lament re-inventing wheels, but often miss that the off-the-shelf wheels each have their own bolt patterns, brake interfaces, and dimensions. And sometimes they look solid, but have subtle defects.
Customers want a hole in the wall, not drill , drill is just one of the tool that can make the hole happen (a manual hammer works too but too time consuming and less accuracy)
Software is just one of the ways for users to achieve their desired outcome (eg: keeping track of business expenses / flow etc) , excel can do it, but some other software might make it easier than excel, with better UI etc.
If you want to succeed in making software, study the users workflow rigorously. "Users don't love software, users tolerate software to achieve the outcome they want"
There is likely 2-orders of magnitude demand for more software than currently exists. Speaking for myself, I have so many different apps I would like to have but would not be commercially viable to build because the problem it solves is very specific to my circumstance. The ROI now makes sense now that I can spin up Claude Code and build apps for these use cases in an a couple of hours so I have a suite of apps that are really just for me.
I think Jevons Paradox applies here: as software becomes cheaper and more efficient to produce (especially with LLMs), the demand for it actually increases rather than decreases.
It's not rare that I wish there were software that would do something, but it doesn't exist or what does exist is terrible. So yes, there is at least some need and demand for more software.
Most of what passes for "software" these days is basically some niche hardcoded workflow that falls to pieces if you try to do anything even the slightest bit different.
So, you might ask "Why are you building X when Y exists". The answer is usually something to the effect of "I can't interface with Y". Programming languages themselves are one of these obstacle. So is linking to system libraries. (e.g. many C and C++ code bases) C-FFI sometimes makes this easier though.
I value low-friction interfaces in software, and I think this is usually not done well.
Another example: I think this is why I dislike Async rust so much. It places a barrier within the language.
Some concrete anecdotes from the past few days: Why am I writing SPME algorithms, asking an LLM to implement a linear constraint solver, etc? Those and many more algorithms that have existed and been heavily used for decades? No/shitty rust libs, and the C/C++ libs have no good way I can interface with, aren't documented well, license concerns etc. I.e., I could try to re-use, but instead re-write because it's, surprisingly, the lower-friction option.
People lament re-inventing wheels, but often miss that the off-the-shelf wheels each have their own bolt patterns, brake interfaces, and dimensions. And sometimes they look solid, but have subtle defects.
reply