Absolutely false. I have built tons of tools which are feature complete and continue to work to this day without intervention. Heck, I even have tools I no longer use that people asked me to keep available because they do, and they’ve been chugging along for over a decade, no bugs or maintenance necessary.
Just today I saw a report of Adobe discontinuing a tool in use by professionals because it is done and they don’t know what else to add.
https://mastodon.social/@grishka/116005782128372247
“Software is never done” is a myth they tell to keep extracting money from you.
A lot of the time, failing to to finish software indicates a badly defined scope.
You might have written software that is "done" if you compile it with a single compiler version and don't use any OS hooks/APIs and don't care if future changes breaks your software. I.e. it's done if you think that people will stop needing to use it at some point in the future.
A tool like sudo can never be done because it integrates with the constantly updating OS and will always need maintenance.
I always had this: "Only dead software needs no maintenance" in the back of my head, and similarly "bug free only means it's not been used and vetted enough"
While probing into this, I think there could be a case where software is mostly done: when it is shipped with the hardware and run in an isolated environment.
The mentioned tools are probably not distributed in binary form for different OS, I assume, otherwise that statement _cannot_ be true.
> failing to to finish software indicates a badly defined scope. In my first job there'd even been a contractual penalty if you are not done in time. And this company produced examples of "finished" software, that controlled warehouse material flow, sometimes running on 20 yrs old MCU. (which of course meant they could not extract money of these customers, because the software ran too good)
It's a bit ironic that digital goods, which are arguably the only products which once compiled can be stored, used, and copied perfectly bit-for-bit, are also the only industry that seems to have this problem with being unwilling to call a product "done".
The reasons for software churn are economic, cultural, and psychological, not technological.
> unwilling to call a product "done"
Unlike modern physical products, software often has a contiguous lineage, with less individual hard cuts between releases, that e.g. necessitate setting up a new production line for each iteration.
Of course you can call individual releases "done" but then you also have to accept that the same realities apply to it that it's utility will decay over time same as e.g. household appliances do, where you also wouldn't use one that's 40 years old.
Calling a software project as a whole "done" (and claiming that it doesn't have bugs and doesn't need maintenance) would be akin to Apple saying the iPhone (the whole product line/smartphone niche) is "done".
> Of course you can call individual releases "done" but then you also have to accept that the same realities apply to it that it's utility will decay over time same as e.g. household appliances do, where you also wouldn't use one that's 40 years old.
Physical appliances decay because of wear and tear, which digital products are uniquely immune to.
Replacing and fixing physical wear and tear is more like having to occasionally clean your logs folder, or reinstall your OS. Admin maintenance on a specific installation, not updates to the product from the developer. The product itself stays the same.
Software churn, updates that change the product itself and not just the way it's run, are more like General Electric requiring you let one of their employees into your house to paint the appliance a new color every month.
> Calling a software project as a whole "done" (and claiming that it doesn't have bugs and doesn't need maintenance) would be akin to Apple saying the iPhone (the whole product line/smartphone niche) is "done".
Which seems like it would be fine? What do 95% people use their smartphone for, that an iPhone from 10 years ago was not already able to do? Besides, this comparison is a bit circular as software dropping support is often the part that forces consumers to upgrade hardware.
Hardware products without software churn do in fact get used basically forever. When they do break, they can also be replaced with the exact same product, without all the issues that running old software gets you.
Apple could make a forever-iPhone that lasts 10 years, or 40 years. But it's more profitable, competitive, exciting, and convenient to release a new product line every year (while turning old hardware into e-waste via software updates).
I'm not saying it's better or worse that things are this way, but it does cause some problems and should not be presented as inevitable.
All that you say is true in a world (or for product categories) that has reached a technological plateau.
The point about household appliances that I was trying to make wasn't about individual appliances decaying (= breaking down), but about the utility of a model decaying over time, as it e.g. becomes uncompetitive because it has worse energy efficiency than it's modern counterparts (or in the case of refrigerators uses harmful greenhouse gases).
Not a great example as that "done" tool (whose currrent iteration barely functions) will be made unavailable after a few years.
That tool is still very much in active use in my industry, and we'll need to figure out what to do with some 10000 fla files that we need to occasionally edit and republish (hint: the solution probably involves a certain Swedish software repository).
> Just today I saw a report of Adobe discontinuing a tool in use by professionals because it is done and they don’t know what else to add.
Yeah, I'm sure the reason stated by the customer support is the real one, and not the lack of profitability from that tool among a shift of focus towards AI[0] as reported everywhere.
https://techcrunch.com/2026/02/02/adobe-animate-is-shutting-...
> for over a decade, no bugs or maintenance necessary
I'll believe it when I see it. Keeping something running for a long time is a lot easier task than building something that can be run in an ever changing world.
Given that it's that old I'd wager that it isn't runnable on/compileable for ARM64 without some kind of maintenance. And if it's written in an interpretable language there is a good chance that the underling interpreter/runtime are EOL by now.
> A lot of the time, failing to to finish software indicates a badly defined scope.
And a lot of the time finished software becomes unused because it sticks to scopes that don't match up with reality/user needs anymore.
> I'm sure the reason stated by the customer support is the real one
Oh, but it's so much more beautiful than that! You're really underselling it! It's not "the reason stated by the customer support", it's:
The reason snarkily paraphrased by a Mastodon post Which quotes a Twitter post Which quotes a Bluesky post Which tells a story about a conversation with an Adobe customer service rep.
Surely that tongue-in-cheek Mastodon post increases the information that we have about this incident by exactly Zero.
Yeah, I have a relatively simple script with webUI for organising photos and videos I take on my NAS.
Over the years I’ve had to upgrade the ffmpeg dependency, which resulted in breaking changes a couple times and maintenance.
I’ve also had to spend nearly a whole day fixing the webUI when iOS’s wonderful liquid glass came out.
How did liquid glass break your Web UI?
Liquid Glass changed dimensions and viewport measurements for fixed position elements, amongst a whole host of positioning related bugs:
https://stackoverflow.com/questions/79753701/ios-26-safari-w...
Many of the bugs were fixed in 26.1, but still, I had to fix it to use it.
I was surprised that not much of the entire web was broken, but a cursory search of commits showed that the WebKit/Apple team took the approach of coding in site specific hacks for popular sites (eg instagram, google search!) for iOS 26.
Maybe I’m not looking in the right places, but I rarely see fixed position elements in modern web layouts— I imagine that’s why you didn’t see more disruption.
They may not be used in layouts, but they can be present in cases like keyboard open (if you wanted to attach some controls above the software keyboard for example); or just ever growing compatibility hacks.
> not the lack of profitability
What “lack of profitability”? They just reported a record quarter. Adobe shoves full Creative Cloud subscriptions down everyone’s throats; buying one tool, especially when it’s not one of the flagships, is uncommon. What exactly are they losing by just letting Animate be?
> And if it's written in an interpretable language
I have never ever ever had to change shell, Ruby, or JavaScript code because “the underling interpreter/runtime are EOL”. Never. That code keeps happily running, doing its work, with whatever version of the interpreter I have available in whatever box.
> And a lot of the time finished software becomes unused because it sticks to scopes that don't match up with reality/user needs anymore.
So what? That’s perfectly fine. Do you drink milk out of a baby bottle? Do you ride a bike with training wheels? It’s perfectly fine to build a tool for a purpose and a time and place and let it exist there for the people who care for it. That’s also true of video games (which, lest we forget, are software). In a world where people are constantly complaining about software updates moving shit around, removing features, and adding crap they don’t want, plenty of people appreciate that the things they like continue to work as they always have.
> What exactly are they losing by just letting Animate be?
Maintenance cost (which you claim doesn't exist) of the engineers that they are planning to staff on other project they are assuming will be more profitable. Of course that's just a bet and not a sure thing.
> I have never ever ever had to change shell, Ruby, or JavaScript code because “the underling interpreter/runtime are EOL”.
I think we are living in different realities. Almost every (open source) project that I encounter that's 10+ years old isn't runnable without changes.
> Do you drink milk out of a baby bottle? Do you ride a bike with training wheels?
Do you still drive a Ford Model T?
its really funny people are so adamant on this while software written for linux 1 still work on linux 6. it is a developers choice to burden themselves with every changing foundations... maybe not the wisest choices in the long run to go for easy things in the short run..
> Yeah, I'm sure the reason stated by the customer support is the real one, and not the lack of profitability from that tool among a shift of focus towards AI[0] as reported everywhere.
Yeah, although "finished" software is antithetical to this always have new features to push onto your customers subscription model, so it's not entirely unrelated.
Having said that I still find it strange. I can imagine it might not be able to ride on the AI bubble, and perhaps animators are especially vocal about not wanting AI in their tools. But even so, why would that make Adobe Animate unprofitable? They do have a subscription model, and customers, so people are paying for this product.
Compared to other digital art, the data for vector animation takes relatively little space to store. It also requires much less resources to render than other forms of video, and rasterized video output should compress really well compared to alternatives, especially with modern codecs that are not only optimized for regular film. So surely it shouldn't be that expensive to maintain for them compared to all their other projects.
> But even so, why would that make Adobe Animate unprofitable?
Sorry, I wasn't precise with my wording. What I meant to say was "less profitable than the perceived AI opportunities they could do with the same engineers".
Ah, ok. Even then switching Animate into "maintenance mode" should be doable on a shoestring budget methinks but whatever, the more Adobe hurts itself the better tbh.
That tool, BTW, is essentially the authoring side of Flash rebranded.
> Absolutely false. I have built tons of tools which are feature complete and continue to work to this day without intervention
And how many of these tools are mission critical to the point that they are installed on almost every Linux box in existence, probably invoked tens of billions of times per day, both by humans and software, and the entire world would be in deep goddamn trouble if there was a serious security flaw that doesn't get fixed immediately?
Because that's what `sudo` is.
And no, such software is never "done".
You’ve moved the goalposts so far away, they’ve left the breathable atmosphere. Look at your condition, it’s over 50 words. I didn’t say “all software can be done”, I just said that it’s not true that software is never done. It’s not a universal truth that applies to all software.