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.
- Set up a test drone--network connected but firewalled for inbound-only traffic if they are paranoid.
- It runs a script using XML::Parser, that monitors an inbound directory.
- Have the owners/admins of the dept. producing or receiving XML data to do daily ftp dumps of stuff they produce/receive to the test drone.
- Whenever an XML file appears there, have the monitoring script parse it, and then simply re-write the XML to a new file in another directory.
- Then, preferably using a seperate non-perl process, use diff or something similar to compare the results and raise an alert if differences are found.
- Have a human procedure that formally investigates and explains the differences.
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:
- You reduce risk by starting out with a tried and tested specification for the XML processing.
- 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.
- 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.
- You raise the potential of saving the company money and reducing time-to-live.
- You establish a possible approvals mechanism (and precident) for adoption of further CPAN modules.
- 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.
Are you posting in the right place? Check out Where do I post X? to know for sure.
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
Want more info? How to link or
or How to display code and escape characters
are good places to start.