Maybe I'm completely whacked here, but I'm not sure you've got time to study your co-worker's code in depth, at least not in the detail you'd like. You've got a week; that's 40 hours of work time. The way I see it, you've got two choices:

1) Hack together a simpler prototype using what you've learned already. It appears that the goal is:

  Is Data Valid?  (Yes) --> Insert into Database
       |
      (No) ---> Send email
[download]

So, try to find the three places in your co-worker's code where he does each single operation, splice that into subroutines, create a simple slurper for your input file that calls those subs, run the above process for each line, and you're out of there.

You might see if MIME::Lite, DBD and other respected modules wouldn't help cut down the lines of code. But, I'd do that later rather than sooner.

At the very least, you should be able to get a working prototype for some basic rules in place, if not all of them. That 1200 lines of SQL code makes me suspicious. Are you sure he's (assumption, sorry) not calling stored procs, defining triggers on the fly, or such? I have seen systems that needed that many lines of SQL--but those are generally run by people who a) know how large they are and b) consequently won't give you something like this with only a week. This is a very basic operation it seems to me. In fact, I'd hope that such a complex data model would already have stored procs and/or triggers in place to do the complicated bits of placing the data into the proper tables. Check for those and use them if at all possible.

2) If you really feel like you need to adapt the mess you're given, then at least give yourself a little help from Perl. Since your coworker chose not to comment, it's either as obvious as Petruchio likes or a complete mess. In lieu of any details, I'm assuming the latter.

Does the code use subroutines? If so, then you'll want to make a list of all the sub declarations and the line they're declared on; use Perl to document this. (You'll need to refer to this while you're reading the code.)

Need an idea which variables are being used, where they're declared, and where they're used? Modify that little Perl script accordingly. Scan for sclars, arrays, and hashes, locate the lines they're used on and then dump the results to a text file. This will help you understand the flow of internal data a little more.

IOW, use Perl's strengths to automatically document--within reason--the existing code. This may seem trivial, but speaking as one that has maintained far too much bad code in his time--including a monolith that used NO INDENTATION (as in none, nada, zip, buptkis. Lines and lines of left aligned code, as far as the eye can see. God, I hated that project)--you need to know as much as you can about that code in the shortest amount of time.

Use Perl's Pathetically Eclectic Rubbish Listing abilities for that. Create cross-references as quickly as you can.

Next, walk through the existing code at a high level and document it using an outline. Make it broad; one comment per 20, 50, or 100 lines or so. Use this as you adapt it for your needs. Give yourself no more than two days to finish the outline.

The outline will tell you what you can keep (can, not should; you're on a deadline...move alone). What you're really after here is what you must minimally change. You don't really have time for expensive rewrites or elegance.

Remember, this is version 1.0. If you hit this deadline, you'll be in a credible position to request permission to rewrite things for version 2.0. It may be cr@p, but functional cr@p is okay for a limited amount of time and as long as no one outside the company uses it.

I wouldn't even call it alpha or beta code, I'd call it "proof of concept" or even prototype code. Then, I'd work toward getting permission at rewriting it to be better, faster, stronger, and so on.

--f

P.S. There is a third, Dilbertian alternative, which I only mention 'cause I've seen it happen. Specifically, this might be a rite of passage, a test, a no-win scenario like the Kobayashi Maru scenario from Star Trek II: The Wrath of Khan. Sometimes, the best career-saving answer is, "I don't know, sir, let me look at things and let you know. I may not be able to do it in a week. I'll do my best to give you an accurate and fair estimate."