[anyonecancode]

> There's this notion of software maintenance - that software which serves a purpose must be perennially updated and changed - which is a huge, rancid fallacy. If the software tool performs the task it's designed to perform, and the user gets utility out of it, it doesn't matter if the software is a decade old and hasn't been updated.

If what you are saying is that _maintenance_ is not the same as feature updates and changes, then I agree. If you are literally saying that you think software, once released, doesn't ever need any further changes for maintenance rather than feature reasons, I disagree.

For instance, you mention "security implications," but as a "might" not "will." I think this vastly underestimates security issues inherent in software. I'd go so far say that all software has two categories of security issues -- those that known today, and those that will be uncovered in the future.

Then there's the issue of the runtime environment changing. If it's web-based, changing browser capabilities, for instance. Or APIs it called changing or breaking. Etc.

Software may not be physical, but it's subject to entropy as much as roads, rails, and other good and infrastructure out in the non-digital world.

[observationist]

Some software - what I take issue with is the notion that all software must be continuously updated, regardless. There are a whole lot of chunks of code that never get touched. There are apps and daemons and widgets that do simple things well, and going back to poke at them over and over for no better reason than "they need updates" is garbage.

There's the whole testing paradigm issue, driven by enshittification, incentivizing surveillance in the guise of telemetry, numbing people to the casual intrusion on their privacy. The midwit UX and UI "engineers" who constantly adjust and tweak and move shit around in pursuit of arbitrary metrics, inflicting A/B testing for no better reason than to make a number go up on a spreadsheet be it engagement, or number of clicks, or time spent on page, or whatever. Or my absolute favorite "but the users are too dumb to do things correctly, so we will infantilize by default and assume they're far too incompetent and lack the agency to know what they want."

Continuous development isn't necessary for everything. I use an app daily that was written over 10 years ago - it does a mathematical calculation and displays the result. It doesn't have any networking, no fancy UI, everything is sleek and minimal and inline, there aren't dependencies that open up a potential vulnerability. This app, by nearly every way in which modern software gets assessed, is built entirely the wrong way, with no automatic updates mechanism, no links back to a website, to issue reporting menu items, no feature changelog, and yet it's one of the absolute best applications I use, and to change it would be a travesty.

Maybe you could convince me that some software needs to be built in the way modern apps are foisted off on us, but when you dig down to the reasons justifying these things, there are far better, more responsible, user respecting ways to do things. Artificial Incompetence is a walled garden dark pattern.

It's shocking how much development happens simply so that developers and their management can justify continued employment, as opposed to anything any user has ever actually wanted. The wasteful, meaningless flood of CI slop, the updates for the sake of updates, the updates because they need control, or subscriptions, or some other way of squeezing every last possible drop of profit out of our pockets, regardless of any actual value for the user - that stuff bugs the crap out of me.

[anyonecancode]

These posts are in a thread about someone pumping out a large amount of software in a short amount of time using AI. I'm guessing that you and I would agree that programs flung out of an AI shotgun are highly unlikely to be the kind of software that will work well and satisfy users with no changes over 10 years.