« Declaration of (job) independence | Main | I am not a "woman blogger" »

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


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. ; )

Posted by Kathy on August 1, 2006 | Permalink


TrackBack URL for this entry:

Listed below are links to weblogs that reference When the "best tool for the job"... isn't.:

» Creating Passionate Users On the Right Tool For the Job from DoRealTime
A must read article both for technology creators and users. Creating Passionate Users asks the question that lurks like a red-headed child in a family of brunettes; When is the best tool for the job not really worth using? First,... [Read More]

Tracked on Aug 2, 2006 9:04:59 AM

» When the Best Tool Isnt, and Why a Growing Team Doesnt Care from J. Timothy King's Blog
Kathy Sierra excellent post on When the best tool for the job isnt misses an important point. Its not that she missed the point so much as she just didnt go into it. But I think it deserves going into. Many s... [Read More]

Tracked on Aug 2, 2006 10:17:36 AM

» Random Thoughts on the Passing Scene #13 from Nick Hodges
[Read More]

Tracked on Aug 3, 2006 11:05:44 PM

» The best tool: the one you keep using from Laanblog
What is the best tool for the job you have at hand? Kathy Sierra advocates the passion you have for a tool helps you learn to use it. Eventhough it might not be the best. Lets try an example. Lets say you are an artist sculptor, and you u... [Read More]

Tracked on Aug 4, 2006 1:51:43 AM

» Random Thoughts on the Passing Scene #13 from Nick Hodges
[Read More]

Tracked on Aug 4, 2006 10:36:54 AM

» Question from the Archives of American Art and EAD talk (session 305) from SpellboundBlog.com
At the end of the Extended Archival Description panel, someone in the audience asked if ColdFusion and ASP were used for the Archives of American Art project. The response was interesting. The answer was yes to ColdFusion and no to ASP. That wasn’... [Read More]

Tracked on Aug 9, 2006 9:33:28 PM

» Tools from Tools
Mac OS Xs streamlined approach to developer productivity decreases your most common and time consuming tasks Naturally, source code for... [Read More]

Tracked on Aug 18, 2006 2:18:05 PM


Don't forget that sometimes the determination of "the right tool for the job" includes a fair slice of the desire to learn something new as well.

For example, I have always found it much easier to maintain the motivation to learn a new language/technique/whatever when I'm aiming at a practical use. If I have a "thing" that I want to produce - no matter how simple - it's a lot easier to maintain focus on learning the new thing that I want to learn.

And if that new thing is the best technical tool for the job, then it's quite probably a win-win situation - the business gets a great technical solution, and I get the mandate to play with the new toys that I want.

(oops - should have included the [sweeping generalization alert] at the start of this post ;-) )

ps. Love your work Kathy. :-)

Posted by: omni | Aug 1, 2006 6:30:55 PM

I've always placed myself in the "best tool for the job" group, so I was all ready to disagree. But I've always defined best as, well, the best. If the learning curve is too steep, or the tool doesn't match the mental model of the user, then it isn't the best. So we agree.

But I don't see the issue as appropriate vs ethusiasm. I see it as the need to take a broad, big picture view of what we mean by "task" or "job".

Of course we should use the best tool for the job. It's the best. But the job is more than just a narrow problem to be solved - it is the whole equation of people, tools, resources, environment, and problem.

Posted by: Jon | Aug 1, 2006 7:57:29 PM

But will you be as proud of your product if it could have been better if only you had used that other, better, but harder to use, tool?

Go back in time a decade and choose between C and Java. Sure, it was easy to write that robust Java program, but the C version ran 10 times faster, even if it took 10 times longer to write.

"The wise man therefore always holds in these matters to this principle of selection: he rejects pleasures to secure other greater pleasures, or else he endures pains to avoid worse pains." - Cicero, 45 BC

Posted by: Michael Chui | Aug 1, 2006 8:11:02 PM

Omni: Oh man, that's such a great comment. I'm going to have to make a whole post about that... I'm so glad you mentioned it. I agree -- this desire to deliberately try something new (especially if you now have a *paid* reason to do it) is something the brain loves. That's how I got started in Java... in 1997 I convinced a client to let me create half the games on their site in Java (rather than Shockwave) because I'd been doing games in Director forever and Java was the exciting new kid on the block. How weird, now, to think of Java as the "mature" thing.

Jon: I wish I'd had you for my boss along the way.

Michael: I was partly disagreeing with this:
"But will you be as proud of your product if it could have been better if only you had used that other, better, but harder to use, tool?"
But only because that really depended on defining "better" and there we go again. But then you got me with the Cicero quote--mainly with the "rejects pleasures to secure other greater pleasures." So I reckon it again depends on how you define "pleasure".
In any case, you make a really good point about that.

Posted by: Kathy Sierra | Aug 1, 2006 9:05:10 PM

Great topic :) actually you're last few posts have all been great. You still owe me a call about pair programming though, which has a lot to do with everything you've been talking about.

Posted by: Jared | Aug 1, 2006 10:02:50 PM

Interesting Kathy. Don Norman (www.jnd.org) makes nearly the same claim in his latest book that beautiful/attractive products do work "better". To paraphrase him: This is because the brain is more effective when stimulated positively. In effect the entire system (human+object) works better.

Training is a system cost, as is lack of productivity due to lack of passion. Over time these things will take a toll if not considered. I have seen this first hand.

Of course, we always assume that the capability to do "X" exists in the tool or toolset. Don't forget the ability to extend your favorite tool with your other helpful tools.

Give someone a small number of motivated people and they can eventually change the world. Rule of thumb: You can usually fix a "skill" problem but is is very hard to fix a "will" problem.

Posted by: Bruce | Aug 1, 2006 10:34:51 PM

I can have all the passion I want in my job every day because I love what I do. But I still can't shovel "it" with a rake.

Posted by: Rick | Aug 2, 2006 6:46:19 AM

Yea, "best tool for the job"?! That assumes the old job and the old tool! So often, the people that make a real contribution to a field are the ones that come in with a fresh look.

Paul Graham makes a great argument for choosing with passion in "copy what you like." I like how he describes his story of learning to copying what he likes. I just linked to him today in "First, You Copy."

Posted by: Senia | Aug 2, 2006 9:14:31 AM

Sometimes you've got to think of the poor guy who comes after you. So every project in the company is done with Access and you come along with your favourite tool and create your system and then you move on. The poor guy after you has to learn your tool, whether they think it's the best or not, so they can maintain your project.

Maybe if you learnt Access then you would have another string to your bow (how many bows have more than one string anyway, where does that phrase come from) and the guy after you wouldn't have reason to curse you.

Posted by: Paul Morriss | Aug 2, 2006 9:38:08 AM

Won't true passion lead you to choose the best tool for the job or turn the existing tool into the best tool?

And doesn't passion allied with the closest tool to hand often lead to bloodshed?

Posted by: John Dodds | Aug 2, 2006 9:56:56 AM

Sometimes too much passion for a tool can blind onesself to other possibilities.

Posted by: Sholom Sandalow | Aug 4, 2006 9:21:11 AM

"Geek street cred goes down as passion for a tool goes up."

Aw, maybe you haven't been hanging out on the right geek streets: the kind where you find arguments about whether emacs or vi is the best text editor referred to as "holy wars".

I've always found the opposite to be true: passion for excellence in tools is often, but not always, what separates real geeks from the corporate drones and clock-watchers.

That said, if your passion is to *get things done*, there is no conflict between best tool for the job and the tool you feel passionate about: they're the same thing. When I feel that conflict, I have to stop and make sure that my priorities haven't gone out of alignment.

Posted by: Ezra | Aug 4, 2006 7:15:37 PM

I am "one tool" person. I think there is a benifit to reducing the amount technology one has to learn. My group at works uses:
Oracel, DB2 and mysql for databases.
Jrun, Tomcat, iPlanet for web servers.
Sun solaris and AIX for Unix.
I think it would be much more productive to use just one product. I find it hard to believe that Oracle and DB2 are so differant that one project should use Oracle and the other Db2.

Posted by: Dave Trower | Aug 5, 2006 9:11:02 AM


I agree with you in principle, but I also have come to realize how often people are passionate, not about the tool but rather about resisting change and breaking out of their complacency/comfort zone.

It is one thing to fully learn a competitive tool and become very proficient in it and then start criticizing its shortcomings, it is quite another thing to ardently claim that your favorite is best because you don't know what you are talking about.

As a web designer, I can tell you why Fireworks is a better tool than Imageready was and also tell you why Photoshop is better than Fireworks. Why? Because I know both products. ( At least I know older versions of both products - grin. )

Passion is often a child of ignorance not just in the computer world but also in the political and religious worlds.

If passion is a sign of bigotry or prejudice, then the favorite tool choice is a shallow veneer for a character flaw. But if passion is due to being fully aware of the advantages and disadvantages of both and making an "informed" decision, then I believe that a craftsman can accomplish more productivity when he enjoys the production process.

Posted by: James Shewmaker | Aug 15, 2006 4:03:08 PM

I disagree that "we're not ready for Emo Programming™".

We crave for it !

Posted by: bille2 | Aug 25, 2006 4:02:04 PM

All I can say is that you are a goddess. Keep up the good work!

Best regards from Deborah

Deborah Elizabeth Finn
Boston, Massachusetts,USA

"What is good...but to do justice, to love mercy, and to walk humbly with your god?" (Micah 6:8)

Posted by: Deborah Elizabeth Finn | Mar 25, 2007 2:56:32 PM

The comments to this entry are closed.