in reply to When to use ORMs, Catalyst, etc
Especially if it'll be a team of 10 developing with me, and 8 may leave in a month, then trying to find people with all those skills, which are certainly a bit hard to come by in my part of the world.
- think the other way around. every new person you hire might
know one or the other framework, or maybe not. that
doesn't matter, they must *all* learn *your* framework.
if you were using a common cpan framework, some of
them might already know it, and if not, they can learn it and they'll find help
on perlmonks.org, for example, because they're not the only ones using it. yes, programmers can learn, and some of them even enjoy it.
- again, think in the perspective of the programmer. if you're hiring, they might not know catalyst, DBIx::Class, but
that's no reason not to hire them because they can learn it.
if you insist on your own framework and for some reason they leave
your company after a while they have learnt a framework
which isn't used *anywhere* else in the world.
- think about *your* perspective in the future - in
some years maybe most programmers know catalyst and you
can't hire them because they don't want to work in a
company where everything is proprietary.
- don't think "it has worked for me all the time, why
should i use something additional?" this *is* how some
people think who haven't used better things. if you have
used ORM or a web framework it is hard to go back to
plain DBI or plain CGI scripts. of course an ORM might
not fit everywhere, but then some other technique that
saves the developer time.
- i'm not saying never ever roll your own, but you should
at least know a bit about the existing modules out there
before saying i don't want that.