http://spectroscopyonline.findanalytichem.com/spectroscopy/Featured+Flash+Component/Understanding-and-Interpreting-the-New-GAMP-5-Soft/ArticleStandard/Article/detail/600799?contextCategoryId=36789 which is explaining the difference in the context of GAMP software classifications.

I think the point Bob makes, that many software vendors try to pass off customisation as configuration is a valid one – and his definition basically boils down to ‘Configuration has a GUI, customisation has code’ – which I think is a good rule of thumb to follow.

In most systems, this type of code would be classified differently than the larger blocks of code that create a new function or feature. This smaller code would normally be checked by a visual check of the screen it is used in to verify that the field filled-in properly. But then, for code that is larger and classified as needing more testing, a formal script (e.g., an OQ script) might be created. There are various written guidelines that projects will create to address this type of classification. One variation on this is that some projects classify code not by size but by what’s in it. For example, if it has no control statements (IF, DO, WHEN, etc…), then it does not get a test script. However, I find this second approach less common.

The projects I have been on often classify code as “complex” or not, for example. Sometimes, merely as “Needs Testing?” with a checkbox on a form. As such, Simon’s term “configlet” would be the same type of thing, really. But Simon, if it’s mini-customization, why not call it a “customizlet”?!