|Just another Perl shrine|
Re^3: What is the best way to install CPAN modules on Debian?by mpeever (Friar)
|on Mar 27, 2009 at 18:52 UTC||Need Help??|
It does not make sense to automatically reject all third-party code. You will waste time and money reinventing wheels. Has that place seriously even written their own versions of stuff like DBI?!
I'm only passing on what I've been told... It's hard to imagine a profitable company in an extremely competitive and fast-paced business that doesn't have a protocol for working around policies where they are counter-productive. I assume there is a process in place whereby CPAN code can be vetted, tested, approved, and added to some sort of whitelist.
The immediate effect on my friend, however, is that he can't search CPAN whenever he runs into a wall with his Perl. When he calls to bounce ideas off me, he generally adds the caveat: "I can't use CPAN."
If we imagine a company with even the most stream-lined vetting process, we still end up with a scenario where a sysadmin's one-off monitoring script becomes a several week effort while he waits for approval for that module. Home-rolling is faster. Even with intense testing and debugging, it'll get the code across the finish line before a module passes review; and a sysadmin doesn't care about portability: the code she is writing has to run on a very specific platform. That removes a huge amount of effort that goes into anything on CPAN.
People in that environment aren't writing frameworks. As far as I know, neither my buddy's employer nor I have ever advocated re-writing a generalized framework like DBI. That's what Paul Graham calls a "pathological edge-case."
In a case where sensitive data is potentially exposed, or where loss of service is measured in millions of dollars per hour, the loss of developer and/or administrator time re-inventing a lot of wheels is negligible by comparison. Additionally, in-house code doesn't have to be portable: operating platforms are concretely known and change very rarely.
From a coder's perspective, using 3rd-party modules makes a lot of sense. But there are business scenarios where it's just not the right thing to do. And in some cases, it's been decided to reject foreign code by default for very sound business reasons. That's my only point.