in reply to Getting managers to accept Perl modules

To expand on lhoward's points, consider some of the basics in developing a large project: Presumably, the specifications are already done, or else you wouldn't necessarily be at the stage of choosing modules. The other issues, however, can be broken out on a very detailed level ... and should be. Proper work up front guarantees a lower TCO. Since many Perl modules are huge, you even find that the one module function you want is not cost-effective. If that's the case, you should be fair and not insist upon using it.

If you like this post, vote up lhoward's post instead. He's the stimulus behind this.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just go the the link and check out our stats.

  • Comment on (Ovid) RE: Getting managers to accept Perl modules

Replies are listed 'Best First'.
RE: (Ovid) RE: Getting managers to accept Perl modules
by 2501 (Pilgrim) on Sep 27, 2000 at 07:36 UTC
    To expand on lhoward's points, consider some of the basics in developing a large project: Specifications
    Design
    Implementation
    Debugging
    QA
     Don't forget "Time". I think one of Perl's strongest points is the fact that solutions can be rapidly developed, programmed and implemented, which is critical in the business world.
    I think if you can present Perl as a tool for the business world to stand alongside VB and java that you might have some luck.
    I also think people tend to forget that agendas between management and their employers tend to differ slightly, and that if you present the problem and solution in their language, and discuss how it meets their requirements that you stand a better shot then if you were to 'get technical' or use an abundance of technically oriented facts and figures to back up your argument.
[reply]

In Section Meditations