BookmarkSubscribeRSS Feed
NKormanik
Barite | Level 11

One might think, as long as there are no warnings or errors, that should do it.

Hmmm.  But you can continue tweaking again and again.

 

At what point do you say, that's good-to-go, release ready!!!

 

Thoughts appreciated.

 

Nicholas Kormanik

 

 

6 REPLIES 6
Kurt_Bremser
Super User
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. But it should regularly be reviewed for possible improvements.
Astounding
PROC Star

Agreed, but I like to add one further condition.

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.

yabwon
Amethyst | Level 16

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

 

 

 

 

 

_______________
Polish SAS Users Group: www.polsug.com and communities.sas.com/polsug

"SAS Packages: the way to share" at SGF2020 Proceedings (the latest version), GitHub Repository, and YouTube Video.
Hands-on-Workshop: "Share your code with SAS Packages"
"My First SAS Package: A How-To" at SGF2021 Proceedings

SAS Ballot Ideas: one: SPF in SAS, two, and three
SAS Documentation



Patrick
Opal | Level 21

You could say a program is release ready when it passes all the quality checks and test conditions. 

On the quality side what's important to me is that a program is robust and "maintainable" (=kept simple, with sufficient inline comments, well structured etc.). 

Also performance is a consideration but there it's always about keeping the balance between keeping the code simple and coding for performance - so it depends on the requirements for the specific program. 

 

I believe you see where I'm going with this: Have the pass criteria defined upfront. And these pass criteria might also depend on how business critical your program is (especially in regards of error & exception handling and how far you need to take this).

ballardw
Super User

I would add that some history of the code as it evolved might be of use.

 

And it may be that the program is never "good enough" for a known reason. An example is one of my projects using external data sources that either were not mature or just plain couldn't keep things standard (column order of variables changing, lengths of variables changing, format of date variables changing, addition/deletion of variables) at irregular intervals. So the program to read the data sets supplied by these sources needed to have some additional comments and data examination with comments related to common changes (I won't say fixes because the fix is going to be temporary) as well has who to contact about things that might appear that weren't self explanatory so appropriate steps could be taken to deal with them.

Plus some comments about likely changes that would be needed in the reporting or other programs that used that data as input. 

 

I won't go into any details about what happens when the data source gets bought out by another company and changes the entire data system  (twice in 5 years)... 

andreas_lds
Jade | Level 19

Just two things i would like to append to the points already made:

  1. The log must be free of warnings and errors.
  2. The log must not contain any unexpected note (like type conversions).

 

hackathon24-white-horiz.png

The 2025 SAS Hackathon has begun!

It's finally time to hack! Remember to visit the SAS Hacker's Hub regularly for news and updates.

Latest Updates

How to Concatenate Values

Learn how use the CAT functions in SAS to join values from multiple variables into a single value.

Find more tutorials on the SAS Users YouTube channel.

SAS Training: Just a Click Away

 Ready to level-up your skills? Choose your own adventure.

Browse our catalog!

Discussion stats
  • 6 replies
  • 838 views
  • 17 likes
  • 7 in conversation