The author was probably meaning "finished" instead of "complete", which gives a different meaning more in line with the article.

I know of quite a lot of software that is "finished" as far as I'm concerned. Developers tend not to think it is, though.

Now, granted, must of us on anything Unix-like is on a BSD or Linux, not on a UNIX, but grep and make are still being patched, here and there. Even 'ls' gets commits. We could get into a pedantic discussion on when something can be classified "finished," but that doesn't seem fruitful. I think we just need to realize that despite following the Unix philosophy (or something similar), which is mainly about modularity and composability, not a single part (modular piece, service, etc.) of modern systems can be left unmaintained, it can never be in a "truly finished state."

This ties in very well with a discussion that happened a couple days ago about whether the concept of "finished software" even exists:

https://news.ycombinator.com/item?id=36877363

That's a really interesting question. I guess some of it comes down to whose perspective we're looking at the software from. I'd tend to look at it from the author/mountaineer's point of view: If Bram Moolenaar had declared that Vim was complete with version 7 and would never add major features like async/JSON support, I'd probably say that the program was "finished", even if it lacked certain features that I'd like it to have. (Those missing features might cause me to use a different piece of software, but I don't think they'd give me cause to complain that the hypothetical Vim was "incomplete")

(And, indeed, there was a period ~5 years ago where it looked like Moolenaar might go that route, especially with respect to async support. My understanding is that his initial unwillingness to add async support/other new features was a big part of the impetus for Neovim.)

> The only way a piece of software could ever stay "finished" without getting new features is, if it was used for something that no longer sees any change happen or any new requirements emerge - it basically has to be a completely non-evolving field of work with static, unchanging requirements.

I'm not sure that the entire _field_ needs to be static. For example, Quake strikes me as a finished piece of software – that doesn't mean that video games (or even first person shooters) aren't evolving. It just means that Quake carved out a narrow section of that field and finished delivering on its design goals within that narrow slice.

I do house projects and have built furniture, and when I “finish” those, there is nothing left to do. There is literally no additional work for those projects I can think of.

I’ve never shipped software that didn’t have bugs we didn’t fix, some feedback that didn’t get addressed, technical debt (test etc.) we didn’t get to, or features we wished we added.

Software is just a different beast to a lot of other things that you “finish”.

We should call it "completed".

> Sometimes finishing is just the beginning: You release the library, the package, the SaaS product, and your work is really just beginning. Users have issues, customers have feedback, and dependencies need upgrading. In some sense, there is no finished software; there is only released software.

This goes far beyond programming. "completeness" is nice but is highly subjective. For work that can be infinitely revised, refactored, recut, "finished" is an idea you impose from the outside, in relation to specific criteria.

The author seems to be saying that there is value in creating smaller, independent modules of things that can be said to be "finished" when they do their thing and no further functionality is added or expected to be added. Further functionality, if needed, would come from connecting "finished" things together, I suppose, or making new things- not over extending a component to handle all cases.

This moves the complexity around a bit and maybe it's more efficient and easier to handle this way.

Artists have a similar problem. It's hard to know when a poem or a song is "functionally complete" but eventually you have to let them go or you never get anything out there.

I'm all for conscientiously abandoning work, especially if the state of the work is well documented so that somebody else could, in theory, pick it up.