Best practise for smart groups

Everyone will have diffrent answers for this based on a lot of factors.

I always find that building some core smart groups that can be reused is the best way I think to reduce clutter and overhead for smart groups. I tend to take those "core smart groups" and leverage the computer group criteria with the member or not a member values.

That said using your example I would create two smart groups. One named Installed - SPSS 24 - Current and another named Not Installed - SPSS 24 - Current.

The criteria for Installed - SPSS 24 - Current would be Application Title is (SPSS24 App Name) and Applivation Version like (latest app version).
The criteria for Not Installed - SPSS24 - Current would be Application Title is (SPSS24 App Name) and Applivation Version not like (latest app version) or Application Title doesn't have (SPSS24 App name).

You could limit this to an AD group for approved users if you have AD or limit it to a static group for users who are authorized for SPSS24.

I find it easier to break it out into multiple Smart Groups - IE, one for not installed and two for if not current version. If I need to check on multiple versions for a policy, I'll still create multiple Smart Groups to individually check on each version. I do this for two reasons 1) They can be easily reused and 2) I've had issues with Smart Groups containing multiple criteria not returning the results I was expecting. Troubleshooting Smart Groups with multiple criteria is a pain - having just 1 makes it much easier.

One factor you should be aware of is the overall size of your database/the number of managed clients you have. I have a very large number of managed clients and from a performance standpoint, I have to use a one smart group approach to minimize the number of groups my JSS has to process. In my environment this keeps my JSS happy, but I agree can cause issues in troubleshooting. Life was easier when I could break the smart groups out, but as my client count kept rising I needed to draw back the number of smart groups.

That being said, smart groups with many criteria (10 plus) or smart groups that have as their criteria membership in another smart group are things to avoid in situations where you have many managed clients. Basically, the more clients you have the more conservative you will want to be in construction of smart groups.

@rcram Another reason I break down Smart Groups is from experiencing the opposite of what you encountered. I had a case with trying to scope certain versions of MS Office to a policy. I created a Smart Group with a few versions and after too many, I was no longer able to really edit that Smart Group. My JSS would just grind to a halt if I tried editing it or viewing membership. When I split it up, my JSS was back to normal.

@ jduvalmtb I find my sweet spot for ease of editing versus JSS becoming generally cantankerous is a max of five criteria. Most of my application smart groups are limited to three (does have "application" and is not this "version" or does not have "application"). If I have to use more I normally have to get creative. That being said, for the larger smart groups I can expect the "Aw Snap" screen from Chrome when I make my edits. I grab a cup of coffee and do other work while it churns. The JSS database just doesn't seem capable of dealing with that type of overhead, though performance has been consistently improving over time.