|Do you know where your variables are?|
Why non-core CPAN modules can't be used in large corporate environments.by Moron (Curate)
|on Dec 06, 2005 at 12:18 UTC||Need Help??|
This was prompted by a number of other threads and I wanted to get to the heart of this matter.
Let us consider the typical case of a production system undergoing enhancements currently, but which first incorporated several years ago, using say Perl v5.004 under either Linux or Solaris. In most cases, and certainly for mission-critical systems, all software goes through a lifecycle of development and three levels of testing (unit, integrated and acceptance), before getting through to production.
Suppose a new version of Perl (say v5.005) came out a year or two later. Before it could be taken through to production, all software developed in the interim would have to be tested against 5.005. That means almost the entire software life-cycle being repeated involving a variety of people from different teams, adding up to an overall expense that is hardly likely to be met by any compensating business benefits the developers can find.
Occasionally some major event will occur, such as a new version of some major package the system uses, whereby the Perl upgrade can be bundled in. But given the cost, such a miracle is only likely to occur about once in five or ten years for the mainstream of corporate systems. It seems normal enough that the version available for download of a CPAN module requires v 5.8 of Perl, whereas the production system will more likely be somewhere between 5.004 and 5.6.1. Maybe one day in the distant future that module may be compatible with these production systems but maybe the minimum for the version in CPAN will be 5.10 or 6.3 by then.
Impact for monks: So, in the meantime, most developers in large corporate environments need non-module programming solutions and core module solutions but cannot use solutions which refer to a non-core CPAN module and for these purposes, core means "core in the late 1990's"!
Free your mind