When I hear somebody say “Right tool for the job” I cringe. The acid in my stomach starts to churn. My blood pressure goes up. I just feel like lashing out or screaming. Why do I get this reaction? Its a simple, logical statement. Sounds like great advice, right? In my experience though, “right tool for the job” is often code for something else. Its an often used, cliche excuse to hide hidden motives. So, let me translate for you the true meaning of “Right tool for the job”.
- There’s this cool fad new language that everybody is talking about. I’m going to use this new language to implement a new feature even though nobody else on my team will be able to maintain it but me. Even though the code will hard to maintain because I’ll be experimenting with every possible new feature of the new fad language I’m using. Thus: New language XXX is the RIGHT TOOL FOR THE JOB!.
- Everybody is talking about this new cool No SQL stuff, but I’m stuck coding RDBMS with Hibernate. Thus: No-SQL DB XXX is the RIGHT TOOL FOR THE JOB!
- This job sucks and I need to train myself in a new technology so I can get a new job. Thus: Technology XXX is the RIGHT TOOL FOR THE JOB!
- My product/project is missing a key fundamental feature that a competing, more mature technology has had for years. I can’t say that this competing older, mature technology is better, I need an excuse so instead I say: You need to pick the RIGHT TOOL FOR THE RIGHT JOB!
Consultants are even more notorious for this.
- I need to make myself invaluable to this company so I can keep billing high rates for myself and my underlings. So, I will find a technology that nobody in this company has experience. Thus, Technology XXX is the RIGHT TOOL FOR THE JOB!
- I need to train a bunch of my new consultants in a new technology. Better to charge this training on somebody else’s dime. Thus, Technology XXX is the RIGHT TOOL FOR THE JOB!
- I need to drum up business, sales are lagging. So, I’ll create a new methodology and pay some Thought Leader to bless the methodology. Then I’ll get my best speaker to troll all the developer conferences touting this new methodology. Thus, Methodology XXX is the RIGHT TOOL FOR THE JOB!
Admit it! You see this happening everywhere. We’ve all done it at least once. But no more for me! Just like I want to purge swearing and cursing in front of my kids, I want Right Tool for the Job out of my vocabulary as well. If you ever hear or see my say this phrase, call me a hypocrite. Flame me. Chastise me. Remind me of this blog!
Bill the Plumber 
Apr 25, 2014 @ 14:47:00
100% agree. This argument is typically used to select the wrong tool! 🙂 I love it when people say things like “well, java really isn’t suited to things like batch processing.” But, when you press them for the “right tool” they’ll either give you no answer or say something silly like “Perl” or some crap.
My other favorite is when it comes to GUIs and the Swing stalwarts tell you that need to use Swing instead of a web app because browsers can’t do things like push notifications, dynamic charts, and grid views. If your frame of reference is IE 7, that might be true. And not there’s anything wrong with Swing (other than it being dated and now in maintenance mode) it’s a hell of a lot more expensive to build and maintain a Swing UI than an HTML5 app running in Chrome.
The “right tool” is usually something in some one’s comfort zone or it’s a shiny new toy they want to play with. Ask a PL/SQL guy what to write a data processing component in, they’re likely going to tell you PL/SQL. In order for something to be the “right tool” it really needs to be compared against the requirements and budget. But this usually never happens and you end up with the wrong too.
Apr 27, 2014 @ 11:14:43
Too black and white 😉 which I suspect isn’t what you mean. For instance … ever tried knocking a nail into wood using a saw? There are exceptions, as with everything. People should base their judgements of a particular tools applicability to a specific job upon all of the available facts. Then maybe, just maybe, that tool is the right one for the job and others aren’t necessarily as suitable (or suitable at all).
Apr 27, 2014 @ 12:57:29
What I’m saying is that more often than not when somebody justifies something as the “right tool for the job” they are more often than not full of shit.
Apr 27, 2014 @ 13:17:52
I definitely agree that in some situations (some areas) people use that statement to justify an choice that really isn’t based on the facts (or “full of shit” if you like). But I’m not so sure I’d go so far as saying that it is the case in the majority of these situations across all use cases/scenarios. Maybe there’s a case to be made that in some areas it’s more prevalent, i.e., more likely to be misused or misappropriated. Now that’d be an interesting thing to research the data on …
May 29, 2014 @ 15:05:34
I want to add another case: I am a manager and I really want to hire this guy, even though I’m using COBOL and he expresses interest in Haskell, he likes distributed systems and high concurrency and I’ve a monolithic mega-server full of legacy code. I know that what I do sucks, but I’m going to insist that I like to use the right tool for the job so that he will see an opportunity that anyway he is not going to get.
This is to say that I agree that this phrase has a high bullshit-potential (I learnt it on my skin), but in my opinion it does have it also on different aspects than the ones you are talking about.
May 29, 2014 @ 18:25:46
The old employer bait and switch?!?
May 29, 2014 @ 21:12:31
Honestly, I disagree. I’d rather have someone saying “use the right tool for the job” than just picking a tool just because they’re familiar it. Too many people are too scared to use anything else, something you just can’t have when technology is moving this fast. The thing I’ve seen come up far more often is the question “can you do this in ?” before the requirements are even known. Basically pick the technology before you know what you want to do with it. Or people trying to “save” money by not buying the right tools where using them would save them MUCH more in the long run.
What I do agree with is that a lot of people can’t back up their statement of something being better with actual proof. And sometimes, even though it is clearly better, it might not be a very good fit for the company for other reasons. You have to take a lot of other things into account as well. The people, environment, the company culture. Using “the right tool for the job” should definitely not be an argument for using “my favorite tool for the job”.
Personally I love using new technologies. I’m always trying out different languages, databases and so on. It gives me all kinds of other perspectives. Of course I have my favorites and I would love to use them all the time. That said, I’m not afraid to recommend something I personally am not into that much if I feel it’s better for the company at that time. It all depends on the situation.
If someone is enthusiastic about something new then let them do a small side project or proof of concept. Maybe do a presentation on it and get others involved. Even when it might not get picked it’s always good to look around and gain new insight. Too many times I’ve seen the wrong tool for the job being used just because people were comfortable with it.
I guess I much prefer the “use the right tool for the job” mentality over the “I’ll stick to what I know best” one, even though it is abused at times. It at least means that someone is willing to try something different and is willing to learn. You need to be aware of what else is out there.
Instead of cringing I’d rather say “then show me”.