Can somebody remind me why software must be maintained forever and it's never ready? Why users cannot compose different existing solutions and instead every application must solve every distantly related problem (poorly)?

Really good questions! I believe it's because our software composition methods are really poor. We live in a world of pervasive reimplementation and yet it seems that's the best we have.

because we don't know how to compose, and we haven't agreed on APIs and data representation across languages that can capture all cases (I guess)

Yes, and bytestream pipes, and the C ABI.

Noticed (read: remembered again) today that one our product which has taken ~10 man years have unique business logic maybe about 1w. Smaller 6 month project have zero, it should be just "basic usage of computer".

I think the answer is our cargo-culted notion of a ‘user’ that we never go back and question: • Users use the ‘same’ program. • Changes to the program go out to ‘all’ users. • Nobody knows how many users some aspect or feature of a program has. Including the authors! • Understanding of how people use a program is poor. • Users can only use programs, not modify them locally. At best they can suggest changes (including code), but the authors control when changes get ‘merged’. • Programs have to be ‘compatible’ and not break existing users. This creates an implicit incumbency advantage where existing users get to lord it over future users. Even if they’re outnumbered by many orders of magnitude! We forget that potential is always greater than reality. So even if you as a single user of a programmer have all your needs met, if somebody else has a feature request, and it’s accepted, you face ‘peer pressure’ to incorporate this feature in your local deployment of the program. Coda or bonus: paying for software doesn’t help much with these questions. Much of what I do involves questioning this social contract. Unfortunately all existing software is governed with this contract, so solving the social problem seems to involve a technical sub-goal. Or maybe that’s fortunate, since I am better at writing code than solving social problems. Maybe I just feel more useful/effective this way? 🤔

Users use the ‘same’ program.

Deep. What if could just transclude only the features we want into our personal bundle of 'the program'. And then remix with our own features. Definitely opens up a whole new direction to explore 'composition'. This is OAP?

This is partly why I’m interested in designing programs to be subsettable. It’s not adding features, it’s the removing of features that’s the interesting question. Our programs all show this complexity ratchet: complexity goes up monotonically over time. But if we forked programs more, and if we deleted features in many forks, that would help a lot in controlling complexity.

Good points. I’m not too worried about unemployment for programmers because of this lack of abstraction and reusability — both in code and in user interfaces/experiences. And the opposite: I think that better abstractions and reusability could bring huge gains in productivity.

i would like to remind the readers of this group that there is a core group of programmers are committed to increasing billable hours and have negative interest (i.e. hostility) towards any improvement in productivity. In the history of computers, at each junction point where a simpler, more productive tool or OS was presented, it was rejected in favor of an inferior choice which produced higher billings. CM/CMS (VMware for mainframes) was rejected in favor of the vastly inferior TSO, COBOL beat FORTRAN, DOS beat the USCD P-system, etc. Anything sufficiently radical will encounter stiff resistance. The users and managers of programmers think differently, but job protection is paramount to many unfortunately.

Maybe the way to go is to not first target "traditionnal" programmers", but end-users or casual programmers instead. They have no interest in sticking to "complex" programming. Once a new way of doing programming is largely adopted by them, reluctant traditionnal programmers will have to embrace it. And if you do it in a way that non-reluctant traditionnal programmers (yet maybe, the more "open" ones) can invest soon you will have something that fits both casual and professionnal programmers.

I find there are two main groups of end-users. Let's call them tinkers and the pros. A tinker's goal is to get a thing done quicker or with less effort. Sharp edges? No problem. A pro requires precision and will invest time and energy to accomplish an effect. As a rule, both groups care more about the goal than mastering technique and theory. I do know few with that trait. Call them musicians: people who see tools as instruments that require practice to use well. Well could "mean" for quick and dirty or perfectly polished.