in reply to Best use of Perl Consultant?

One big problem with having a consultant doing the job you describe is the loss of experience/knowledge for the company when the contract ends (I understand that this product is part of the core of your company's business). I doubt that it is possible to counter this loss by the production of documentation etc. My experience with these kind of systems is that understanding and documenting them is about as much work as repairing or even rewriting them.

Therefore I would try to attack this problem by hiring a consultant to build a testbed system for the application, with enough tests in place to guarantee a working application with the main features. This is in itself an added value, so the investment will be worthwile even when the consultant goes. The time scope for this should be a relatively small part of the whole schedule (less than 1/5 of the time schedule you have for repairing the application?).

Then use/hire an experienced coder to refactor the system, adding more tests as you go, but be sure to keep the refactoring experience inhouse, as this is the core knowledge to work with and maintain the product.

Christian Lemburg
Brainbench MVP for Perl
http://www.brainbench.com