the "no good Perl jobs"/"no good Perl programmers" myth

[Aaron Trevena]

On 07/08/06, Adam Turoff <ziggy at panix.com> wrote:
> The *real* problem is that they couldn't attract truly senior staff to
> apply some design to a festering hack (due to said horrible mismanagement).
> As a result, the Perl programmers they *did* manage to find were
> generally junior level programmers who were just barely capable of
> hacking the hacked hacks to meet deadlines.  Eventually, this plan will
> run out of steam, and they'll probably revisit the "do it in Java"
> plan with gusto.

I've seen this in a couple of places, one place is still recruiting
perl and java programmers and I believe still hasn't (after years and
years of meaning to) actually moved to Java, the other place instead
decided to shell out for a new technical directory and some halfway
decent contractors.

One is probably still losing money and looking for java programmers
the other has been able to continue using the old code-base while the
new code base is tested side-by-side with the ability refactor or
replace instead of rip and replace.

Given the choice I'd take the refactor and replace option as you can
change the goals from 100% replacement to 10% depending on your
business needs, and get improvements in performance, reliability and
possibly even new features for your money.  You'd get some
improvements in performance and reliability porting a crufty perl
project to another language, but lose the ability to control how much
it costs - if you're lucky you can split into chunks sharing the same
database, but it's likely you'll end up having to rewrite 100% of the
code base and not get any immediate benefits for anything between 12
and 36 man-months depending on the size and complexity of the
application.

cheers,

A.