The project was in a programming language I didn't know (and it wasn't used at the company) with a tight schedule. And I knew I wouldn't be able to finish it in time in the quality I want to provide. Plus as a Java developer I wasn't that interested in that particular programming language (Perl).
How else would you handle such a situation?
Often part of a technical job, particularly a technical job with any interesting work or responsibility, is educating your boss about the true costs associated with a decision so that they can make good decisions. If they want you to do it in Perl, that's fine, they're paying for the time and you've informed them why it will cost more than they thought. It's a good idea to follow up with an email restating this so that there's a written record you can point to later when the project falls through.
Honestly, I had expected that you'd refused a project that was unethical or illegal, not that you'd just decided you weren't interested in the stack they wanted you to use. If you told me that story during an interview, I certainly wouldn't hire you. It shows a level of inflexibility as a developer that makes me seriously question if the reason you refused the work is because you're not capable of picking up another language.
Above all else, be positive and constructive.
For example, say that your current skills in Perl aren't great, but that you're certain you can come up to speed fairly quickly. Then point out that the work will probably not be of great quality unless you have to time to do that, and poor code executed quickly will certainly lead to more problems further down the line, so you really want to make sure that the company's code base remains clean and without unnecessary technical debt.
Then express enthusiasm again, and ask how you can work together to get the work scheduled to ensure it's of decent quality, while still meeting the company's timing requirements.
Solve the problems, and get the boss involved in solving them with you. Say that you're willing to do it, and welcome it as a learning opportunity.
A point for concern is your response that you're a Java developer with no interest in a different language. I would hope that most developers would welcome the chance to get experience in another language. New languages are either easy to pick up because they're similar to something you know, or hard to pick up because they are extending your skills and making you more able, adept and, in the longer run, valuable.
Try to see yourself as a problem solver, not just a Java programmer.
Of course, sometimes, you end up doing the work anyway, but the 'disclaimer' in your "Yes, and..." give you a position in which to work where your boss implicitly buys into those limitations -- this is also a better thing.
"Yes, and... {limitations}" instead of a no is always a better answer to a superior. Most of mine have seen the light after discussions like this when something was a bad fit or bad idea.
On the other hand, sometimes I ended up having to do the undesirable. Take pride in what you do, no matter how undesirable, and you will find yourself building excitement for your work. You may discover you learn some cool stuff along the way, too.
Best of luck!
It's not that I'm not interested in a different language (besides Java I use other languages, too), it's just that I was not interested in Perl.
I agree with you about the value of learning new languages, but I think you are more successful in learning a new language when you learn it because you want to learn it, and not, because you must learn it. Intrinsic vs. extrinsic motivation.
If you're very valuable to your employer, you might be able to get away with saying "no". But most people are not indispensable, and if you say "no" too many times, your employer will start looking for ways to replace you.
Why is it so important to your boss that the project be done in Perl? You need to understand this so you can see if there are other avenues you can pursue that will make him equally satisfied. For example, using Ruby or Python.
And why is it so important to him that you do the project in Perl? As you said, you don't even know Perl. Why isn't the project going to someone who does know it?
If you're lucky, there will be some alternate win-win path to helping your boss accomplish the goals he wants accomplished without getting stuck doing work you really don't want to do. Or you may have to sign up to do a certain amount of scutwork, but get your boss to agree that once you're through the current crisis, you can move on to a path that you will find more rewarding. If a good boss understands your career goals, he will work to find a way to help you work toward them. And the better you are at helping your boss solve the problems he faces, the more likely you are to discover that you have a good boss.
Of course, it's also possible that the reason you're being assigned this task is something to the affect that there's a lot of other Perl in the company, and the company wants to crosstrain people in Perl. Perl is just part of the deal there.. In this scenario, not learning Perl is effectively declining to develop essential job skills, and your only realistic option may be to suck it up until you can go find a better job. Just be glad it isn't COBOL! (Sorry, gallows humor there.)
It was an existing project developed by the client, and they used Perl. So the technology was fixed.
> And why is it so important to him that you do the project in Perl?
That wasn't important, I was just the guy with some free capacity.
> As you said, you don't even know Perl. Why isn't the project going to someone who does know it?
There was none who knew it (at least as far as I know), the company was a Java shop.
"OK, I'm totally on board with what you want to do, but I wanted to give you a heads-up about some problems I foresee. You want me to do Really Hard Thing and have it to you by Friday, but as embarrassed as I am to admit it, I don't think I'm quite good enough at Really Hard Thing to have it in a condition I'd want to present to you by Friday. I mean, I'll give it my best, but I felt like it would be irresponsible not to tell you so you could make a decision with all the relevant information. If I can make a suggestion, I think it might be better if we do More Reasonable Thing. It seems like the ultimate goal is to do X, Y and Z, and More Reasonable Thing will still do all of that. Alternatively, is there any wiggle room in the schedule so I can make sure you get it in the condition you're expecting?"
What exactly do you think you do that the company pays you for? It isn't programming. Programming is just a tool you use to solve business problems.
Good: clearly tracking the risks as the project progresses.
Better: pushing yourself to learn Perl and mitigate the risks to the best of your ability.
Best: spend some OT implementing it in Java and show her why it is better (or show yourself why it is not).