Some of your reasons sound convincing on the surface, but they neglect one huge factor altogether: scaling.
If you establish a procedure by which you can distribute CPAN modules to the production machines, you have access to many modules. Establishing the procedure is O(1) (you only have to do it once), but reimplementing the modules that you otherwise can't install from CPAN is (at least) O(n), ie must be done for each module.
The same scaling argument goes for maintenance costs: you can let them (ie the CPAN authors) do the maintenance, or you can do yourself. Which option do you prefer? Which option does your employer prefer? Is it your job to maintain reimplementations of maintained CPAN modules?
PERFECTION I'm a perfectionist, and fear someone else's code may be sloppy or not as fast as it could be.
Being guided by the mere fear is irrational. Just look at the code, the tests, the ticket queue. If the code is actually sloppy, slow and bug-ridden, then you have a good reason not to use that module.
But beware, there is a common pitfall. When people approach a domain that is new to them, they often look at software that deals with that new domain, and think "oh my god, this is over-engineered, overly general and complicated crap; I could do much better". And then they reimplement everything in a cleaner and much simpler way, until they find out that their solution doesn't quite cover all cases, and that handling them all would require much of what the originally rejected module did.
The lesson to learn is that a reimplementation of a module often takes much more time and effort than initially thought. The main reason is lack of domain knowledge. The main (BAD) reason for reimplementing modules is overconfidence in your domain knowledge.
In reply to Re: Top 11 (GOOD) reasons not to use someone else's Modules
by moritz
in thread Top 11 (GOOD) reasons not to use someone else's Modules
by miketosh
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |