Those people who know me are probably tired of the articles I continue to write on the (mis)usage of the words “configuration” and “customization,” over the years, but I feel it’s my mission in my professional life to find a way to eradicate or clarify these terms.
As we continue to talk about why we have project overruns, it continues to befuddle customers that they could purchase a COTS (Commercial Off-The-Shelf) system that merely requires some configuration, and end up with an expensive project full of programmers writing code for them. This is due to the fact that what some (i.e., the customer) might conclude would be configuration is not the same as what another (i.e., the person selling the services to the customer) might consider it to be.
What Do They Really Mean?
I claim that “configuration” is when you press a few buttons to change the behavior of a feature. I don’t agree that you could write “just a few” lines of code and still call it configuration. I say that having seen what some people would call “a few lines.”
I also claim that “customization” is when you write code to change any behavior in your system, not just that of the core of the system. I have been on too many projects where a module is “configured” to work in a customer’s situation by writing thousands of lines of code. Once again, leaving the customer to wonder why the project is taking so long and costing so much.
Finally
With all that said, I realize some of the terminology we use is used in a way to mollify some of the regulatory agencies. But are they being mollified or are we just misleading them? I can’t quite figure that out.
But I will make everyone a deal: if you all just stop using these words in a confusing manner, I will stop my constant whining and writing about this topic. I promise to move onto another worthy topic, such as then getting rid of confusing and misleading terms like “COTS.”
[...] Metrick takes on “Configuration” Versus “Customization” on The Integrated [...]
To comment further on Simon’s examples, I want to start with the example of small bits of code. So, I agree with Simon that small bits of code should be handled differently. It is common in many systems to add 2-3 lines of code to pull field values into templates and screens, for example. Sometimes, we really mean that we have a single line of code plus a RETURN statement to make two total lines of code.
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”?!
One of the best definitions I’ve seen on this topic is here :
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.