Work with their system, and use it to your (mutual) advantage.

If you were going to implement your own, in-house version of say, XML::Parser, the first thing you need is a specification document: use the XML::Parser documentation as your spec. Pretty much the next thing you should be designing is your test suit, test data and acceptance criteria.

Offer this as your test procedure.

Management willing, that shouldn't take more than a few days to set up at the start of the project. You then sit down to write the rest of the application--the part that uses XML::Parser-like clone you are going to write--using the XML::Parser interface, and using XML::Parser as a substitute for your own clone for development purposes.

If by the time the rest of the application is written, the test drone process has highlighted serious or repetative errors in XML::Parser, then you can set about writing (or refactoring) Your::XML::Parser, with the additional knowledge gained of the originals weakspots and deficiances. If however, it proves to be reliable, then you have saved the company money, and hopefully gained a little respect/qudos for yourself and CPAN at the same time.

Write everything up as a proposal up front, nothing hidden. Your bullet points for presenting the proposal and the management summary are:

  1. You reduce risk by starting out with a tried and tested specification for the XML processing.
  2. You allow the a fast start for the team developing the business processing part of the application, by decoupling their development from the XML parsing development through a mature interface design.
  3. You get a head start on discovering anomolies and problems routed in the inbound XML and decouple those problems from the rest of the development work by isolating them before they get there.
  4. You raise the potential of saving the company money and reducing time-to-live.
  5. You establish a possible approvals mechanism (and precident) for adoption of further CPAN modules.
  6. If XML::Parser (or other chosen module) proves not up to the job, and you have to write your own, many of the above benefits will still have been acheived, and the few days of effort required to set up the test-drone are more than offset by those retained benefits.

If you think that it would be viewed in a sympathetic light, you could add a not-too-obscure footnote somewhere to the effect that if the process pans out and the company does adopt the module, therebye saving X man-hours/$1000's in development costs, that a contribution by the company to the Perl Foundation of some percentage of that savings would be beneficial and gratefully received.

Examine what is said, not who speaks.
1) When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.
2) The only way of discovering the limits of the possible is to venture a little way past them into the impossible
3) Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke.

In reply to Re: Production Environments and "Foreign" Code by BrowserUk
in thread Production Environments and "Foreign" Code by Tanalis

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":