in reply to Getting managers to accept Perl modules

Expanding a bit on jcwren's mention of support costs...

If you're going to convince a manager, it helps to speak some of the language. The most legitimate reason (IMHO) a manager can object to a Perl module is called Total Cost of Ownership. From the point of view of the programmer writing the code, installing a module is a no-brainer; it makes writing the code easier. But the Total Cost to the organization isn't just the time and disk space to install the module once. It becomes a job for a system administrator to install on every server/workstation which will run the software you write that uses the module. And adding that to the list of software installed on every new system that comes in the door. And upgrading the module to the next version that fixes a crucial bug. And...

These are all solvable problems, to be sure, and the particulars will vary from company to company. But you'll get farther convincing management to install modules if you take a little time to think through some of these issues and address them when making your case.
  • Comment on RE: Getting managers to accept Perl modules

Replies are listed 'Best First'.
RE: RE: Getting managers to accept Perl modules
by Fastolfe (Vicar) on Sep 27, 2000 at 00:06 UTC
    But see, I consider Perl modules to be extensions of the language environment itself. A company choosing to develop in Perl isn't going to balk at the fact that they have no IP interest in the Perl language itself. Same with the modules. Perl modules are typically written with some very flexible licensing. You can generally distribute Perl modules with your script under most any license, and if the distribution of a module is impeded by the fact that you're trying to sell your script, all you have to do is provide instructions (or a properly built package so that CPAN can extract the dependencies on its own).

    At that point, the only thing to complain about is the fact that this huge project has turned from a 2-month, multi-10-thousand-line application to a 3-day Perl script, making extensive use of pre-written modules. Some companies intent on making a bundle from such an application are going to get iffy about it when they find out the resulting script is only a few hundred lines.

    Note: Code samples are for conceptual use only and generally are not meant to be cut/pasted into a production application. Always 'use strict', have a thorough understanding of the code you use, and check the return values of functions and handle errors according to your needs. - Fastolfe

[reply]
[d/l]
      But see, I consder Perl modules to be extensions of the language environment itself.

      Fine. I agree with you. But guess what? The manager who objects probably doesn't, or s/he'd allow you to use the module, yes? You'll be more persuasive if you set aside your own viewpoint for a moment and try to address the manager's concerns in ways that make sense to the manager.

      For (too) many organizations, it doesn't matter that Perl's licensing is flexible and that modules are easy to install. Using modules save programmers lots of time, but represent additional work for someone, and that costs $$$. Your argument will be more effective if you take the time to find out (or estimate) that cost and then show how much more money is saved by using the module anyway (a cost-benefit analysis). Trying to argue that the manager is looking at it "incorrectly," or that there aren't any associated costs, is just more likely to make him/her stop listening.
[reply]

In Section Meditations