Software is never finished, it’s always just ‘good enough’.

Highly dependent on what features I need from the software in question and what the alternatives are. For a business case, I would probably go with 3. I deal with software deployments at my company, so I know how bad some bugs can be to the business. For games, I tend to go with 1. For other software, 3, as I’m not really a power user for things like photo editing, spreadsheets, etc.

Complexity alone is useless.

If you do something simple software can’t I’ll accept bugs.

If you do something faster or easier for me as a user then I’ll accept some bugs but less than the impossible case above.

If you do something i could do faster and easier with a stable command line software from 1992 I’ll not use your software until you fix it.

3. Unix philosophy goes BRRRRRR

However, if 3 is not possible because it’s say, a game or something where complexity is the point, then 1.

There is a road in Poland. A4 it’s called. It’s officially a highway but never in it’s history did it satisfy requirements for that title. Label of highway cannot be removed for as long as road is under repairs, renovations or upgrades.

So there is a highway that shouldn’t be one, permanently in construction and never finished. It’s also paid road, one of the most expensive roads to use in EU.

And yet people still pay to use this road because alternative is a slower route through smaller roads and varied towns.

Software is the same - your application can be buggy shit, but as long as it’s best buggy shit available people will prefer it over more finished ones.

“FINISH HIM!”

As a user, would you rather (1) wait for them [the software dev/company] to get all the bugs out,

I don’t expect to live eternally and certainly don’t expect to wait that long ;)

As a user I factor-in the various bugs/issues/constraints I have to deal with using any software to decide if it’s worth it or not. If it i snot I don’t use it.

Note that I also factor the freedom/privacy-respecting aspects of any software, as a user I mean.

Code quality is actually quite distinct from an applications feature set. Something that was vibe coded in a week can have similar features to something that took 2 years for a dev team to bring to maturity, however the actual code base will be on a completely different level. Not all applications care about all of these things: Security, scalability, stability, performance, low resource consumption, test coverage, readability, effort to customize and extend.

If you are creating a dating app or a device driver you will naturally have different preferences for the code base.

The end users opinion is secondary to the opinion of the company or person who owns the software. The software is an asset that the company uses to run its business. If pissing off 50% of your user base is acceptable business strategy, then they may opt to cut corners in places which will result in dissatisfied users.

The real question is what is the goal of the company. Most companies main goal is profit, but in some cases like nationalized government services, non profit organizations, providing a core service offering is the main goal. In the latter case it may be acceptable to have shitty UI and some broken parts of the application as long as the important functionality works.

Then there is the tradeoff between investment (good developers are usually not free) and essential vs nice to have features. Maintaining a minimum viable product is non negotiable while assessing experimental features for market desire will have a reduced budget and have more tracking for return on investment.