If I can add anything to the above, I would say that it will help if your initial effort is spent on laying the foundation to start out with a certain degree of relaxation and then to actively maintain sanity along the way. Then you will be able to cheerfully go about your tasks.

I can tell you that if you just let this thing loom in a way that can pull a dozen gotchas on you along the way, you will not have fun.

Perhaps you would start by making a list of subroutines and globals to start with and try to understand general program flow, what the main operational modes or usage scenarios are. This will help you think about architecture and perhaps simplify the interface.

I would recommend spending time doing profiling - what sections are really ugly or have the most lines, and therefore will take the longest - and set yourself up for a string of successes every few days. You can practically schedule them.. and this data actually will help you understand how long it's going to take your team to finish the job by doing resource allocation - how much time is each person going to able to spend on it. A skeleton program with placeholder subs - which you would get after fleshing out your new architecture from scratch - will then work from the beginning and then just work better and better as time goes on. Maybe the first iteration just shows the screens you would see so that your client can try it out. You may get some more requests for changes then, which is okay as long as you can manage the load (treat it like a real project with a deadline and manage risk) so it is not a never ending story.

Another thing I could say is to document each routine with input and output parameters, and how it is expected to be used. I do this and try to include a "Usage: $ret = &myfunc($x)" line inside the sub's comments so it becomes like a little black box. Maybe you have a better way to do API documentation, but I like to keep it to 3-5 lines at the top of a function so I get a brushup whenever I go look at it. You can do this before the heavy coding. Maybe you'll also take the time to write some pseudocode in comments in those subs. This might allow more people to help you by working in parallel, and it also reduces the amount of work anybody has to do on a given task too. Keeping tasks small and well documented is important if you are going to be putting little bits of time into it over it and not just churn on it for a few days straight. If possible I'd really recommend getting 2-3 sequential days to hit a given subroutine and finish it so you can save the time it would take to get the project back into your memory.

Also I would recommend considering this to be a new application, and even if abbreviated, to carry out all the steps you would normally do if it was a brand new system, including writing a short "What this is supposed to do" report, then a spec, and then sample interface mockups (coding unnecessary), and then for each of these steps get your "client" to agree with you, or go through iterations of each until you get agreement, on each step. This way, you can be sure that your client is supportive and will be happy because he knows what he's getting. And you have a chance to reconsider everything.. are you sure you want it to look like *that*? and so on. Get all the bad vibes out before coding, then you get to spend your time on controlling feature creep and thinking up great code instead of always battling with issues that "aren't your fault".

Maybe you do two iterations on top of that product development dialogue, in which the "client" is first a programmer on your team; talking it over with someone else helps you keep perspective too. I suppose this leads into what XP says, where you have two programmers to a terminal. I think I'd prefer two programmers in close proximity working on different sections, since they can then help each other, get pizza, read PerlMonks, etc.

Have fun!