• Does it do exactly what I want it to do? It can be the greatest module in the world, and yet still not be useful to me. If I'm trying to do signal analysis on my MP3s, LWP::Agent won't help me much.
• What is the state of the code? If it's a mission-critical application, I want released, well-tested code. If it's experimental, it's reasonable to use some more cutting-edge, alpha code.
• How well-tested is it? For critical applications, I'd want to take a look at the build tests and see if what I'm trying to do with the code is tested at build-time. This will save hours of agony when upgrading.
• How well-documented is the code? Documentation is important in its own right. Also, good documentation is the sign of a conscientious author and well-tested code. (Although not an infallible one.)
• How conscientious is the author? An active mailing list and a helpful maintainer can make up for a number of module-related sins.

However, if the module fails any of these tests, my first impulse isn't (or at least shouldn't be) to shrug my shoulders and rewrite from scratch. Instead, if the fundamental design of the module is good, and it merely suffers from some missing features, testing gaps, or bad documentation, the best alternative is to spend at least an hour trying to fix the problem yourself, then send the patch to the author. (Much of this is situationally dependent-- if the project is due in 45 minutes... well then I've already messed up.)

I won't claim to have followed this philosophy completely in the past, since to be honest I hadn't thought about it much. I will follow it in the future, though. :)

stephen