It’s not primarily about bugs, it’s about everything constantly changing, from UI, look&feel to how features work. This is a constant cognitive load to users, a perpetual need for them to readjust to the changing software. As a result, the software never feels finished, doesn’t feel solid, and often appears not to be well thought-out. This gets in the way of the “it just works” the user wants, in a major way.
The argument is not against enhancing and improving the software, it’s against delivering a “draft” (as you say) to end users, it’s against constantly changing the design and working of features. Delivering a “draft” (or prototype) is only acceptable for beta users, or in an initial design phase involving the future users in the design process. It is not acceptable for released software intended for productive use.
Users want stability. They want the software to get out of their way as much as possible, to be reliable and unsurprising, to remain working in the familiar way.
That has barely anything to do with treating delivered software as unfinished drafts.
If requirements change, then this has to be carefully coordinated with the affected users, in particular if they aren’t the ones defining the requirements, or if the user base is not uniform and the requirements may only change for a portion of them. In any case, requirement changes affecting how users operate existing functionality shouldn’t be a frequent occurrence.
The argument is not against enhancing and improving the software, it’s against delivering a “draft” (as you say) to end users, it’s against constantly changing the design and working of features. Delivering a “draft” (or prototype) is only acceptable for beta users, or in an initial design phase involving the future users in the design process. It is not acceptable for released software intended for productive use.
Users want stability. They want the software to get out of their way as much as possible, to be reliable and unsurprising, to remain working in the familiar way.