When the "best tool for the job"... isn't.

[sweeping generalization alert]

Programmers / software developers fall roughly into two camps when it comes to choosing languages, frameworks, etc.:

1) Those who want to use the tool they love

vs.

2) Those who say, "use the best tool for the job"

The "best tool" group makes a compelling argument. It's the most logical, for sure.
The "best tool" group (correctly) recognizes that passion for a tool can cloud your judgement... the "If all you have is a hammer, everything looks like a nail" syndrome.

The "best tool" group is sensible, smart, and unemotional.

The "tool love" group, on the other hand, has a less compelling case. Too much attachment to a particular tool has that tinge of emotional irrationality. Geek street cred goes down as passion for a tool goes up. But given the inherent "rightness" and moral superiority of the "best tool" group, I still think it's worth looking more deeply.

First, just what the hell DOES "best tool for the job" actually mean? Best at what? I think we usually take it to mean, "most appropriate for the task"). But is appropriateness-for-task really the best criteria for "best"? That depends, of course, and NOBODY advocates using a tool that completely sucks at the task you're faced with.

But what about learning curve? Available resources? Shouldn't the appropriateness of the tool be balanced against how much expertise you have in that tool? There must a threshold at which using the best-tool-you-don't-know ends up being a less productive and perhaps less performing choice than choosing a tool you know well that while UP to the task, isn't perfect.

There are tradeoffs everywhere, of course. For example, let's say I can tweak and hack a tool to do what I need, more productively than with the tool I don't know... but those hacks might hurt maintenance down the road. But still...

So current expertise has to be factored in and while I believe most sensible project managers do, I've had way too many emails (and students) who were pushed into learning a new tool in a week by someone who has no clue how LONG it takes to get really good at some of this. Learning curve needs to get a bit more respect.

But you knew where this post was going... the "passion" factor. How much weight should the love you feel for the tool get? A lot more than it usually gets. Yes, there's irrationality that must be tempered and challenged by those who don't share that passion. And yes, there's a tendency to frame the problem in terms of the solution you already know. But even with all that, the benefits of passion are so often underrated.

Think about it. From everything we've learned here reverse-engineering passion, the one most consistent attribute we find across things people are passionate about is learning. When people are truly passionate about something, they want to learn more and more and more. They invest time and effort getting better, not just because they're forced to by their job, but because they genuinely enjoy being better at it. (hi-res experience and all that)

I think too many people underestimate the value of that drive to become more expert, and what it could mean to a project.

Now, I'm NOT suggesting that you NEED passion in order to be an expert and do the best job with a tool. I'm saying that passion (or at least a Big Like) should be factored in to the mix when choosing the "best tool for the job".

When we talk about "best tool for the job", we should look not only at "best for the task", but also "best for those who must use it." Ahhhh... you can probably tell that I just returned from OSCON, where Ruby/Rails love (and still a whole lotta Perl love) are in the air.

Once again, I'm reminded that this is a great time to be a programmer, because people ARE starting to care about Creating Happy Programmers (see also David HH's original eWeek article on Programmer Happiness)

So perhaps we're not ready for Emo Programming™, but there's still more to choosing a tool than what's right for the task. We cannot weigh the appropriateness of the tool without factoring in both task appropriateness and user relationship with the tool. ; )