in reply to Opinions on migrating Perl scripts from 5.005 to 5.8.1?

Is there a comprehensive test suite and complete documentation for this script? I'd guess that there isn't, so I suggest you should write them. Ensure that your documentation states clearly how the script should succeed fail under normal circumstances and under all the various error conditions, then make sure your test suite tests every single one of those failures. Then write tests for success (IMO easier than testing failure, simply because you can generally succeed in far fewer ways).

Once you have a test suite, validating your code on the new version of perl becomes a *lot* easier.

  • Comment on Re: Opinions on migrating Perl scripts from 5.005 to 5.8.1?

Replies are listed 'Best First'.
Re: Re: Opinions on migrating Perl scripts from 5.005 to 5.8.1?
by Lori713 (Pilgrim) on Sep 22, 2003 at 15:28 UTC
    The consultant didn't create any test suites, and there's only a little documentation in the form of comment lines. I've contacted the consultant and it seems he's in almost the same position I'm in now... being very new to Perl and having to grab code from other Perlers, even if he doesn't completely understand how it works. I'm finding my confidence level isn't very high in my ability to completely re-write the code from scratch, especially since it's a little complex (at least to me!).
[reply]
      Not documenting is a terrible sin, especially for someone who is being paid a great deal of money and who is not going to hang around to perform the needed maintenance. However, divining what the code does and writing the documentation will certainly be a worthwhile learning experience. If you can find the original requirements documents and specifications (assuming they exist!) they should make the job easier.

      As for the confidence thing - at least you can feel superior in making use of community resources and Doing The Job Right when compared to that overpaid underperforming wastrel of a consultant :-)

[reply]
      Slightly off topic but I have to get this off my chest. When hiring a contractor to produce code, of any kind, stipulate that they must provide clear documentation in order to complete the contract. Get it in writing.

      Neil Watson
      watson-wilson.ca

[reply]
        If only ...
        • ... managers were that wise
        • ... organizations had documentation standards a contractor could follow
        • ... organizations were ... well ... organized enough to store documentation in a sane manner
        • ... requirements were clearly documented
        • ... requirements didn't do a 180 in the 3 days before production
        • ... contracts actually went the length agreed upon (I'm being smacked by this one ...)
        • ... a lot of things

        It's all well and good to say that, neilwatson. Even if I wanted to provide documentation of the code I'm producing right now, I can't! I never received specs, support, or even time to do it right. I have to lie to my management in order to write tests. In fact, the group that pays my contract isn't even the group I'm writing the code for. And, I don't have a person in the group who's going to own the code to hand over ownership. And, my manager doesn't care! (Well, maybe he cares, but he doesn't see the priority.)

        My situation is normal. It's even somewhat expected.

        ------
        We are the carpenters and bricklayers of the Information Age.

        The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]

In Section Seekers of Perl Wisdom