1. Have you done this kind of thing before? Can I see a sample of that work?
2. How long do you think it will take you to do this?
3. Do you have any other projects running simultaneously, or will you be focussing all of your efforts on this project?
4. Project or hourly pay?

My advice - find a company who give you a day's trial with the new kid, to evaluate whether a) they can cut the mustard b) if they can fix yer table problem.

A lot of companies (at least in London) provide the "One Day Free" situation so that you can decide whether the contractor is the right person for you. Aside from jumping in head first and hoping there's water in the pool, this might be a valid option.

Azatoth a.k.a Captain Whiplash

A new hire is a (hopefully long-term) investment. One thing that you should want to decide is how well you think this person is going to learn. A person who will learn what you need them to know and then continue learning is worth far more than a person who just knows what you are working on. I would, and have, recommended someone who didn't know Perl over someone who did for a job as a Perl programmer based on how well I thought they could learn.

A consultant is a return on someone else's investment. You do not expect to get a long-term return on anything you put into that consultant's skills. You may have to train them, but you should regard that training as a sunk cost. So the entire aspect of whether you think you can train them becomes very secondary. Even if you can, you don't want to. Do they already know what you need them to?

Neither of these positions is, of course, absolute. Permanent employees go elsewhere, and you tend to work with a consultant for a while. But it is something to keep in mind.

I've been on both sides of the table, and I can vouch for HyperZonk's advice above. The technical questions to ask a consultant are the same you would ask any candidate. In this case, you can even concentrate on the specific items you need: Perl, CGI (I assume), SQL. After you've gotten past those, consider the business questions: have a budget (both time and money) and see if you can work out a contract.

As for gambling: well, every time you add a person to a team, you're taking a chance whether they'll work out or not. On a number of occasions, I've had a person who interviewed very well turn out to be a dud (both permanents and consultants). It happens to the best of us. At least with a consultant, if the person doesn't work out, you can cut your losses quickly. On the other hand, if they work out great, you may want to bring him/her back for the rewrite.

Speaking personally as a consultant, I would love an opportunity where the client called me in to fix one specific thing. It would give me a chance to show what I'm capable of much more than any interview ever could. So don't feel uncomfortable about giving the person what may seem like a small (trivial, tedious, pick your adjective) task.

HTH

Would it not be a more effective use of time to use the temp to offload the work of a current employee that already has already familiarity with the application/code?

As you are leery of just removing the temp tables as the scope of the candidates requirements get the full potential scope on paper. It will probably help you get a better picture on your evaluation criteria.

I don't think you are gambling, but as you are planning a complete rewrite (and you are apparently currently under-staffed) you might find this project as a time to look at options to hire and this project as a weeding ground for a potential new-hire.

This may be less important if you're going for the quick fix on temp tables only and have a well-focused description of that task, but could be really important if you're hoping to get someone for a longer-term assignment.

someone who doesn't want that job, despite adding a job qualification that would include him

They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

If, on the other hand, you're planning for a man-year or more, I'd take a deeper look at your rewrite plans. Maybe they're too ambitious?

As for how to hire a consultant ... as a Perl consultant myself, just make sure that the person (or people) have the Perl skills you require and that s/he has the project debugging skills you require. That's all that was done when hiring me (and the other 6 Perl consultants in the shop I'm at). I've done two technical interviews already and that's what I was directed to inquire about.

On a more introspective note, I'd personally go after your previous manager and shoot him. Encouraging static temp tables and polluting main:: should be reasons for justifiable manslaughter. :)

The best use of a perl consultant would be on an easily tractable/dividable problem, with available resources such as documentation and staff who can explain the details, and a comfortable deadline.

It looks like this project has none of these. Time-constrained triage of a large, badly written program where the coder has left is probably as difficult a consulting gig as I can imagine.

It seems to me you need to knock down as many obstacles as possible. I would suggest hiring as expert a coder as you can find, who comes well recommended by others, and who has an established track record finishing difficult projects within similar time constraints as your project. Prepare to be sanguine about the deadline when the consultant has a look at the code and suggests twice as long as you think you have.

Don't hire an additional consultant with the expectation it will go twice as fast, and if that still sounds like a good idea, read The Mythical Man Month first.

It is also possible the best option is to head for a rewrite now.

___
-DA
> perl -MPOSIX -le '$ENV{TZ}="EST";print ctime(1000000000)'
Sat Sep  8 20:46:40 2001
[download]

I know quite a few Perl consultants as well at various levels of competency, from coders comfortable in the trenches to highly qualified architects and DBAs.

In answer to some of your simpler questions,

• I think hiring a consultant with knowledge of Perl, RDBMSs, and E-Commerce implementations for the architecting of the system would be extremely wise. I would recommend them to handle architecting, design, and code reviews, particularly since you're considering a rewrite at some point.

  I would not recommend using them for project management. Also be aware that you may not be maximizing your value if you spend money to hire someone with an architect's experience and saddle them with alot of coding duties.

  These observations come from years of experience. If you don't have folks on staff with the existing core competency to do what you're proposing (that is, someone who's done it for years and is considered effective at it), you will save your company reams of time and money by outsourcing the architecture and refactoring.

• I would also recommend segmenting your needs, and perhaps hiring a consultant to perform a less-time-intensive task first and evaluate their performance before you use rely on them further. There's alot of signalling during the hiring of a consultant, but you never really know until you get the goods.
• If you don't have anyone with strong Perl, RDBMS, or E-Commerce skills on staff, I would also recommend hiring a consultant just to help you interview other consulting candidates. If you're up-front about their role (i.e., so they don't consider themselves to be in the running for the job), their perspective as a disinterested 3rd part will improve the results of your interview phase considerably.

I'm afraid a response in this forum for some of your more general questions would be far too inadequate given the complexity and general nature of your problem. However, I would be happy to discuss your questions in more detail or provide you with some names of folks who I have worked with in the past and who are both highly competent and possess a high level of personal integrity.

Send me an e-mail (note that you have to replace -at- with @) if you'd like to chat more :-)

Hope this helps!

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

I would also be EXTREMELY picky about vendor selection. One large computer company, with a substantial consulting practice, once supplied a previous employer with four consultants. Of those, three were unequivocal disasters:

• One of them didn't know how to tee output to a file. Consequently, he kept trying to do Windows NT line printer dumps to a network printing facility that was actually a postscript-input filter on Unix for an otherwise-network-connected laser printer. If that last part doesn't make sense to you, it didn't make sense to us either; it was one of those "Why the H$@$ are you doing that for?" moments.
• The second one actually predated me by a couple months; it was a quick stint to write some administrative scripts for a Unix cluster, so that configuration changes made on one would be propagated. Apparently, nobody taught this particular programmer that path-substitution is a good way to hack poorly-written setuid scripts; there wasn't a single hard-coded path to anything called within them.
• The third one was ostensibly a C programmer in Unix. However, he insisted on editing everything on his Windows laptop; he then had to be trained on how to upload his files (!!) to the servers, and how to use a C-compiler from the commmand line. I have no idea how (or whether) his C code actually worked, but my experience as a sysadmin with him was that he was effectively clueless.

So, YMMV, but I would look for vendors who can supply individual consultants who can demonstrate a pattern of past successful deliveries of e-commerce consulting IN perl ON YOUR PLATFORM. Just because someone is a multi-billion-dollar company doesn't mean they don't have idiots working for them; statistically speaking, they should have n times as many idiots as a company n times smaller.

Spud Zeppelin * spud@spudzeppelin.com