Can’t software be done? No known bugs, all features in a proposed scope written. Done and done.
This is the part that I doubt will ever be achieved by any system or structure of moderate complexity or above. Everything that exists in the real world has problems with it. If it's a building or a machine, then it's done once it's built unless there are major safety issues. The cost of fixing non-critical issues in a physical product is too high to justify.
The problem with software is that the marginal cost of "one more fix" is close to zero, which means that declaring something "done" means drawing a somewhat arbitrary line in the sand. Why is this new complaint less important than the similarly-scoped one that you fixed last week? There's not really a good answer to this question, so there's never a good day to say that you're not fixing anything more.
Modern construction requires a significant amount of maintenance. The Romans on the other hand, they knew how to build a building!
When I refer to problems that go unaddressed I'm thinking of problems like "this bathroom is too small", not "the roof needs replacing".
I was raised with the rule of thumb that you should budget 1% of the purchase price of a house for maintenance; while that's roughly true for my century-old villa that I purchased at the turn of the century, I suspect that the hockey-stick of residential housing has made it a bit inaccurate.
And something that I didn't really understand until an architect cousin explained to me is that modern commercial buildings mostly have a designed lifespan, typically 50-100 years.
Modern buildings, on the other hand, feel cheap and their unlimited flexibility leaves them with no inherent character.
https://www.cs.vu.nl/~ast/Publications/Papers/computer-2006a...
That's too high a standard. If nothing else, differences of opinion over the design are sometimes classified as bugs. No known bugs worth the effort to fix and deploy is acheivable.
Most NES software is done, none of the bugs are worth recalling to update roms.
> At the time of my death, it is my intention that the then-current versions of TEX and METAFONT be forever left unchanged, except that the final version numbers to be reported in the “banner” lines of the programs should become TeX, Version $\pi$ and METAFONT, Version $e$ respectively. From that moment on, all “bugs” will be permanent “features.”
I think he's getting pretty close to perfection - his report on it https://tug.org/TUGboat/tb42-1/tb130knuth-tuneup21.pdf and hopefully he'll live to do the next one in 2029.
His dedication to the unchanging format is important, I can compile ancient TeX documents that are almost older than I am with no changes, and I can compile LaTeX documents almost as easily.
* https://github.com/Stichting-MINIX-Research-Foundation/minix...
Then this one turned out to be a chat request.
* https://github.com/Stichting-MINIX-Research-Foundation/minix...
And this one the author actually asked to be closed, because the problem is fixed. It's still open.
* https://github.com/Stichting-MINIX-Research-Foundation/minix...
If those are any indication, this is an issues list where no-one gets rid of the rubbish, and it thus its existence alone tells one nothing at all, as one probably is going to have to weed a whole bunch of very clearly non-bugs out to determine if there's anything left.
tambourine_man posed a valid hypothetical, but that's all it is: hypothetical.
If remodeling buildings had the ROI that continued development of software does, that would happen all the time too.
Things like Docker demonstrate all that matters is encapsulation by those interested in keeping these projects live.
So it surely doesn't apply here.