4 ms·

Well the question here is, what criterion is more important for being finished: A.) having a complete and stable set of core features B.) no more new features

by hooby 6y ago

Well the question here is, what criterion is more important for being finished: A.) having a complete and stable set of core features B.) no more new features being added To me personally, A.) is way more important and way more indicative of "finishedness" than B.) is. Surely both criteria do play into this - but imho there's more weight on A.) than there is on B.). Let's look at your example: VIM. According to criterion A.) it is finished - because it has a complete and stable set of core features, which haven't changed much in many versions (and many years). According to criterion B) VIM is absolutely not finished, because it still is under active development and new features are still being added. Let's look a different example - I suggest looking at a piece of imaginary vaporware. Maybe a few design documents exist - but not a single line of code has ever been written. The project has been canned before it even started. No new feature is going to get added to this software ever. According to criterion B) this software does count as finished - because no new features are being added. According to criterion A) this software is not finished at all, because it doesn't have a single core feature, let alone a complete set of core features. Now those two examples are sitting at the very extremes... things do get more interesting if we compare two examples that are a bit closer to the middle: Which one is more finished? 1.) A piece of software that just hit version 1.0 - it has all it's core features completed, is fully usable, but is still under very heavy development, and might release 2.0 sooner rather than later. 2.) A piece of software sits at version 0.8 and all development has ceased. It's mostly complete, but still missing a few core features - but it's no longer getting any updates at all. I personally tend to see 1.) as the more finished piece of software of those two. And that means that to me, having a complete set of core features is more important than no longer having new features added. I simply can't see 2.) as finished, since it's incomplete even at it's core. I believe the Vaporware example shows, that you totally have to weigh in "complete set of core features" as well. Imho at more weight than "no new features" has. And when weighing things that way, a piece of software with a stable set of core features can be pretty finished, even if new features are still being added. Simply because that complete-set-of-core-features part is so much more important than the no-new-features part.

ghoward 6y ago
I have to admit that A) is, in fact, now important than B). I guess I apply that standard without thinking about it.
codesections 6y ago
I don't entirely disagree with your perspective, but evaluating what counts as "a complete and stable set of core features" gets very tricky. For example, you said > Let's look at your example: VIM. According to criterion A.) it is finished - because it has a complete and stable set of core features, which haven't changed much in many versions (and many years). From my point of view, that's not an accurate description of Vim. Vim 8 (released in late 2016) added several new features. Most notably: > Vim can now exchange messages with other processes in the background. This makes it possible to have servers do work and send back the results to Vim. See |channel-demo| for an example, this shows communicating with a Python server. (Source: https://raw.githubusercontent.com/vim/vim/master/runtime/doc/version8.txt https://raw.githubusercontent.com/vim/vim/master/runtime/doc... ) I personally view this as a major new core feature – one that enabled a whole new class of plugins, including many Language Server Protocol plugins. For the ways I use Vim, that's a core feature. Maybe it's not a core feature for you, but that's exactly my point: what is and isn't a core feature depends entirely on an individual's usecase. > Let's look a different example - I suggest looking at a piece of imaginary vaporware. Maybe a few design documents exist - but not a single line of code has ever been written.… According to criterion B) this software does count as finished - because no new features are being added. I agree that criterion B) would characterize this as "finished", but I disagree that it would count as "finished _software_". Maybe it's a finished design document, but if no software was produced, then it's not finished software. Incidentally, it's obviously possible for software to be both 100% finished and not very useful. For example, the K&R C "Hello, world" program is finished – it doesn't need any updates and perfectly fulfills its specification. But that doesn't mean I'm planning to use it daily!
- hooby 6y ago
  I fully agree - that can be very tricky indeed. But I think your response on VIM does add another great point to this discussion: nobody would have considered VIM incomplete for not having JSON support, before JSON even existed. In theory, VIM could have been complete AND finished earlier without JSON-support, back in the day before JSON. But then JSON happened - and suddenly VIM suddenly no longer had a complete set of core features. And not being complete means not being finished - since being complete is pre-requisite for being finished. And doesn't that mean, that a piece of software which does NOT get new features, can't stay "finished" when things change and new requirements emerge? Doesn't a piece of software have to get new features so it can stay (close to) finished - and doesn't revert back to being incomplete? 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. But any active, evolving field of work will always see changes and new stuff and subsequently new requirements will emerge. Software has to react to those changes in requirements.

by hooby 6y ago

ghoward 6y ago

I have to admit that A) is, in fact, now important than B). I guess I apply that standard without thinking about it.

codesections 6y ago

I don't entirely disagree with your perspective, but evaluating what counts as "a complete and stable set of core features" gets very tricky. For example, you said > Let's look at your example: VIM. According to criterion A.) it is finished - because it has a complete and stable set of core features, which haven't changed much in many versions (and many years). From my point of view, that's not an accurate description of Vim. Vim 8 (released in late 2016) added several new features. Most notably: > Vim can now exchange messages with other processes in the background. This makes it possible to have servers do work and send back the results to Vim. See |channel-demo| for an example, this shows communicating with a Python server. (Source: https://raw.githubusercontent.com/vim/vim/master/runtime/doc/version8.txt https://raw.githubusercontent.com/vim/vim/master/runtime/doc... ) I personally view this as a major new core feature – one that enabled a whole new class of plugins, including many Language Server Protocol plugins. For the ways I use Vim, that's a core feature. Maybe it's not a core feature for you, but that's exactly my point: what is and isn't a core feature depends entirely on an individual's usecase. > Let's look a different example - I suggest looking at a piece of imaginary vaporware. Maybe a few design documents exist - but not a single line of code has ever been written.… According to criterion B) this software does count as finished - because no new features are being added. I agree that criterion B) would characterize this as "finished", but I disagree that it would count as "finished _software_". Maybe it's a finished design document, but if no software was produced, then it's not finished software. Incidentally, it's obviously possible for software to be both 100% finished and not very useful. For example, the K&R C "Hello, world" program is finished – it doesn't need any updates and perfectly fulfills its specification. But that doesn't mean I'm planning to use it daily!

hooby 6y ago
I fully agree - that can be very tricky indeed. But I think your response on VIM does add another great point to this discussion: nobody would have considered VIM incomplete for not having JSON support, before JSON even existed. In theory, VIM could have been complete AND finished earlier without JSON-support, back in the day before JSON. But then JSON happened - and suddenly VIM suddenly no longer had a complete set of core features. And not being complete means not being finished - since being complete is pre-requisite for being finished. And doesn't that mean, that a piece of software which does NOT get new features, can't stay "finished" when things change and new requirements emerge? Doesn't a piece of software have to get new features so it can stay (close to) finished - and doesn't revert back to being incomplete? 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. But any active, evolving field of work will always see changes and new stuff and subsequently new requirements will emerge. Software has to react to those changes in requirements.