I'm getting "schrodingered" here, i.e. I agree and (partially, or "semi-") disagree with what @Kurt_Bremser and @Astounding shared, or maybe you can say: "I agree with some buts..."
A) "But it should regularly be reviewed for possible improvements." - this I 100% agree, no "but", no need to discuss. 🙂
B) "As soon as it does what it is supposed to do, in reasonable time and without overloading the resources (CPU, storage, memory), it‘s good for release." - my first "schrodingerisation" - I agree with "as soon as it works OK", but not sooner than it is documented. There is a fair chance that writing a user friendly instruction will save you more time than any refactoring, optimisation, etc. Speaking about optimisation, let's have in mind Knut's "Premature optimization is the root of all evil", sometimes (e.g. for business) it's more important "to have it running", rather "to have it running fast" ("fast" my be achieved as one of later points during reviews [see previous paragraph])
C) "When you have simplified it enough so that the people who need to use it can do so easily, without running to you with questions every time." - my second "schrodingerisation" - I agree that the code should be simple, but I dare to say: simple for you - the developer/maintainer. From the user point of view, I'd say that your code interface should be simple, i.e., the way a user runs the code should be simple, not necessarily the way your code computes things under the hood (basically sometimes calculations and computations cannot be done easily).
Having shared my thoughts, now, a shameless plug.
Let me share my approach to: "this is the way I consider a program to be good enough". 🙂
I would say a code (here considered in a general sense, as a "bunch of programs doing something") is ready to be shared (as good enough) when it's encapsulated as a SAS package (and workshop).
Why? When building a package you:
1) have to have your code running right (i.e., doing the thing it suppose to do),
2) you have to have it structured (i.e., divided into "units" of work that can be easily maintainable, and when combined together "make" the program)
3) you have documentation in it (even automatically combined together in one single document if you provide the text as markdown)
4) you can add tests to package generation process, so every time you change something it will automatically be verified (i.e., that the change doesn't break your expected results)
etc.
When such a package is generated it "envelopes" your code in a single file which you give to a user and don't have to worry about things like:
- "it doesn't work because I'm missing a piece of code" - everything is in that single file,
- "it doesn't work because I've executed it in wrong order" - it executes in the order your meant it to be,
- "It's so complicated because there are 153 components under the hood" - you set user's interface through one documented macro call,
- "it doesn't do this thing you said it does" - you have versioning (and timestamp of creation) so you can easily verify if user have the right version
etc.
All the best
Bart
