I posted a graph on LinkedIn. It showed that of the 10 million open source projects tracked by ecosyste.ms, more than half haven’t been updated in two years. I didn’t suggest old was bad or good, but I got a number of replies about most of this software is “done” so it’s fine. We don’t have any evidence either way, I’m unwilling to make any claims about the numbers (yet, I’m working on it). This got me wondering what it would mean for software to be “done”. Which then led to the question is anything ever done? It’s a lot harder to figure this out than I had expected.
I would say doneness is about completeness within context, not immutability.
The environment may change, but within context, it can still be considered done.
It’s fine to say and consider software never done, because there are known and unknown unknowns and extrapolations and expectations. But I think calling something done has value too.
It is a label of intention, of consideration, within the current context. If the environment changes and you want or need to use it, by all means update it. That doesn’t mean the done label assigned previously was wrong [in its context].
We also say “I’m done” to mean our own leave, even when there is no completeness on the product, but only on our own tolerance.
In the same way, if you shift focus, done may very well be done and not done at the same time. Done for someone in one environment, and not done for someone in another.
More often than ‘done’ I see ‘feature complete’ or ‘in maintenance mode’ in project READMEs, which I think are better labels.
Mmm, interesting. Doesn’t Haskell have a monad that represents everything external to the program, for like producing I/O? In some ways I suppose that mentality makes explicit this idea you’re expressing that the environment the program runs in is implicit in the program? A software equivalent of “no man can step in the same river twice, for neither is it the same river nor is he the same man?”