in reply to Getting managers to accept Perl modules

When trying to convince managers you have to bring it down to the fundamental things they work on: time and money. When presented with a project come up with 2 estimates. One based on using modules (be sure to add the additional time it takes to install the modules on all the necessary machiens). The other based on writing (and testing) the functionailty that you need to re-invent from modules. Let the manager choose. If he doesn't choose to use modules (almost always the cheaper solution) he will have to justify to the layer of management above why he choose the more expensive option. In my experience it is frequently much more expensive to re-write module functionality than to use existing modules (1 day vs 2 week projects, etc..).
  • Comment on RE: Getting managers to accept Perl modules

Replies are listed 'Best First'.
(jcwren) RE: (2) Getting managers to accept Perl modules
by jcwren (Prior) on Sep 26, 2000 at 23:38 UTC
    This whole thread brings up several points that management needs to examine before accepting/rejecting a module:

    1. Does the management and/or engineer suffer from NIH (Not Invented Here) syndrome. This is a very real, and sometimes fatal, affliction where the perons involved will not accept a module/component/device/etc merely because it was not invented by their company/department/team. I saw this a fair amount at IBM, and I've heard that Motorola is notorious for it. This is often a matter of pride, sometimes a matter of distrust (which is a variant on pride), and occasionally a legal matter. Accepting a component not developed by your people/department/company can lead to support availability issues, etc, that may play a factor.
    2. Are there practical ramifications to not accepting a module? It may indeed make *your* life easier, but what are the licensing requirements? Will it place your company in an undesirable position? If it's an Open Source module, and you are not a Open Source embracing company, this places you in violation. Developing your own component (and let's use this to cover just about anything we need, large or small, software or hardware) keeps your proprietary knowledge just that. Information may want to be free, but the shareholders don't always see it that way.
    3. What are the long term support issues in the module? If you have a problem, will your people be able to figure it out? If it's a closed source component, and the company goes out of business, will you be seriously up a creek? (Obviously, the Open Sourcers will start going nuts right about here, but I'm taking this just a little past the Perl module discussion). Do you have rights to the source, if said company goes out of business?
    4. What's the reliability of the component in question. We (Perl developers) have this tendency to trust CPAN modules. "Oh, they've been out there, they're debugged". Well, that's just utter nonsense. Some of those modules have only been out there since yesterday, some are so little used as to have no history, there are seemingly endless updates for others. Yet, we trust them. Now, if you've got the source, sure, you can fix them if you find the bug. If you're smart enough, anyway. How many of you think you could really fix something in Parse::RecDescent? What's the security, for certain modules? Do you *really* want to trust an enterprise financial package's core security functionality to a module with no history? (And you Open Source nuts, calm down. Just having the source doesn't mean you can see/find/fix/understand any/all the security holes. Security holes can be more than just an 'if' statement looking for a checking account number. Sometimes it's a race condition, or other trickier, less obvious beast.

    While I readily agree that some of these examples are slightly outlandish, they are very very real. They represent concerns that *real* companies (that know what they heck they're doing) have. Open Source obviates a few of these, but doesn't necessarily fix the legal issues.

    It's for reasons like these that companies would rather pay you 8 times what it's worth for you to write it. At that point, the company owns it. Assuming you're a half decent programmer, and you're programming for what you're paid, and not for job security, the company now owns that technology, free and clear (you weren't stealing that idea, were you?). Free and clear doesn't just mean licensing issues, either. It means they own the technology, which adds value to the company. A company that is built on a product that they don't own all the components of, or don't understand the technology of, is pretty worthless (unless you've got a management team that are consumate scam artists. Been there, seen that).

    Anyways, I hope this has provided some enlightenment as to why companies can't always go to 'Free Wheel Depot'. Free is not always Free, nor always Best. And Dog help anyone who gets me started why companies shouldn't hire consultants most of the time... (Even though I am one! I love to consult, I hate consultants!)

    --Chris

    e-mail jcwren
[reply]

      JCWren raises some seriously good points in his post, and has given me a money-making idea that I offer free to the community... why not form a commercial Perl module certification service?

      CPAN testers do what they can to make sure that a module passes its own tests on different platforms, but there's little checking on what those tests are all about. Not a criticism-- people have jobs to do.

      So here's an opportunity for someone to make some extra cash. Start a company that verifies and supports Perl modules for a price. If you discover bugs, fix 'em and give the author your changes, and the whole community benefits. Paranoid bosses can feel better with some corporate support they're paying for.

      On the other hand, I've worked for some fairly large companies-- HP and 3Com-- and the divisions that I worked for had no problem with the use of CPAN modules, so long as I was willing to vouch for them and fix any problems myself. (Thank god I rarely had to do that...) If one explains this to one's boss, one's boss might get entranced with the wish to play like the big kids play. (On the other hand, "because this guy on perlmonks said this is what they do" is unlikely to carry much weight, but hey...)

      stephen

[reply]
        I believe ActiveState offers support for their distribution of Perl (which isn't limited to a Windows version), so in a way this is already taken care of. If management wants a supported Perl solution, they can buy it from them.

        Though I don't know how 3rd-party modules are handled. I don't know if you have to get your modules via ActiveState, or even if ActiveState supports 3rd-party modules. I might suggest this to them if they don't already do that over creating a new company to start from scratch.

        But hey, competition is always good.

[reply]

In Section Meditations