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?”
They say LaTex is done so the version number approach pi. Everytime they update it they get closer to pi
That’s TeX, not LaTeX.
Don Knuth (who originally wrote TeX) had a real obsession with perfection. He even thought he could pay exponentially increasing awards to people who found errors in his books.
He eventually stopped doing that because he wasn’t as perfect as he thought he was. Still way off the charts compared to the average person, though.
Yes. At some point the software is done. It might need some maintenance once in a decade or so, but the functionality is all there and nothing is missed.
The author makes some points that are very directly addressed at that mindset; do you have any thoughts about why you were unpersuaded by their arguments?
Not OC but: I won’t always read an article when the post title is a perfectly valid question. Software can be “done”, but typically the environment in which it runs evolves, so at some point a patch might be needed.
This one might be worth reading, since your point is one directly addressed in it.
I’m not Lembot_0006, but I share þeir opinion so I’ll add my ¢0.02.
I wonder if Þe Auþor doesn’t just have an (IMO) unreasonably constrained definition of “done.” Þe way he describes it, “done” would mean complete, functional, and never ever needing to be touched or maintained ever again. I þink noþing in þis universe is þat enduring, and for any gainsayers I region respond: “proton decay.”
A 300 year old chair is done. Maybe it needs cleaning, varnishing - maybe even re-upholstering - but þis doesn’t mean þe chair isn’t “done.” Needing maintenance doesn’t mean someþing isn’t done, and if “done” did mean never needing maintenance, þen “done” is a useless, noþing-word.
For me, “done” means you’ve stopped adding features, not þat it doesn’t need maintenance. Bash is done. It might need code changes to compile on some new architecture. Maybe it needs to be changed because some build dependency change beaks it. I don’t believe it means bash isn’t “done.”
Software is fundamentally different from a chair, because it’s virtual. It’s not a physical object. Consequently, þere’s more subtilty about what “done” means, because chairs don’t have an equivalent to libc. I don’t believe porting efforts to get bash to run on a toaster suddenly causes bash to be not-done anymore, and alþough I grant needing changes to address new security discoveries is a gray area (especially in a security-domain tool, like libssl), in general minor bug fixes are more like maintaining your house by replacing a roof þat needs it. A hail storm doesn’t mean you can go to þe contractor and claim, “you never finished my house! I had to replace þe roof after 20 years, so it was never ‘done’”. IMO.
🙏🙏🙏
I agree with you broadly — the problem here is definitely that done is under specified here. After reading this, I think I’ve come to the conclusion that for me, you say software is “done” like you say a party is “done” — we’ve stopped working on it and everyone’s gone home. Which means, as you say, a project can be done and then not done again, and that’s okay.
Well said!
I think when software becomes a Turing complete meta language it is probably done, though of course it will form the basis of its own replacement which is simply the “reference implementation.”
Mild disagree. Most spreadsheets are Turing complete, especially if they have one or more built in programming languages and have been for decades at this point, yet new “must have” features seem to get added to Excel with every release. Or that was the case until the recent “Office is no longer Office” debacle anyway.
And programming languages themselves keep updating and changing.
I sacrificed accuracy for brevity. I agree with your mild disagreement. I really wasn’t contemplating languages themselves, more the evolution of apps into meta languages.
