Re: Loyalty, Personal gain or Professional Integrity

[seattlejohn]

In my mind, the question is not about "betraying Perl", it's about (potentially) betraying a customer. Now, I can't tell from your post whether you're talking about an internal project or one for an outside client -- and I would argue the standards are different for those two cases.

Clearly it's valuable both to you and to your company to broaden your technical horizons, so using a project as an excuse to develop your Java knowledge is not an intrinsically bad thing. (In fact, you may even find that learning more Java makes you a better *Perl* programmer!) Where I'd start to get worried is if you are doing that learning at the expense of a paying customer. If your lack of experience with Java relative to Perl is going to cost them more money, or result in an inferior product, then it seems to me you need to do some hard thinking before you make that recommendation.

If this is for an internal project, I think you just need to be honest about the tradeoffs with your manager, etc.: "Hey, boss, this may take longer to complete because I'm not as proficient in Java as in Perl, but in the longer term having the knowledge of Java's relative strengths and weaknesses will enable us to make better implementation decisions." Make your thinking explicit and get approval for the tradeoffs you're proposing. (There may be project constraints that you aren't aware of that would make this a really bad project to experiment on.)

Your broader question about people's biases leading to bad IT decisions is an interesting one. I'm frequently amazed at how fervently programmers (and technology people in general) get attached to particular tools. To stretch an analogy really badly, I love the swiss army knife that is Perl, but there are times when the right tool would be a torque wrench or a pickaxe or an electron microscope, and using the swiss army knife to accomplish the task would be less than optimal.