(edited Nov 11, 2011: re-worded links because I didn’t mean to insinuate that Schurter’s “Failing with MongoDB” fell into the cateogory of “didn’t know why they choose a tool” – I meant to point blame at some of the responses it spurred)
My issue with node.js is with the users that have decided to use it for no other reason beside that it’s the hip new thing; users that don’t understand the ramifications of running all your requests in the event loop. And it seems there is an excess of such users.
But let’s put poor node.js aside for now. It has its moments where it really shines. This same issue exists with all tools.
There is no tool for every situation
There is, and never will be a magic bullet. Take programming languages: you can come up with irreconcilable downsides for any language. C? Not very dynamic, too much having to manage memory, no OO. Ruby? Too much magic going on, overloading builtins dangerous. Python? Not as fast as C/Java, threading is weak (WTF GIL), no compile time type checking.
However, every single argument against can be reframed to be an argument in favor. Sure, it’s dangerous that your co-worker can introduce a library in your Ruby project that overrides how addition works with numbers (basically breaking anything other code that requires adding two numbers together), but such freedom gives you metaprogramming superpowers, and the ability to make some really nifty DSLs. Sure, there’s no compile time type checking in most dynamic languages (as the Haskell fans tend to claim, due to this their code works bug free the first time around <<- take with a grain of salt), but at the expense of that you gain productivity and the ability to do rapid prototyping.
The same thing happens in the datastore realm. Recently, there has been a storm of anti-MongoDB sentiments being raised (see here and the hackernews comments related to this post). What it boils down to though, are the complainers not understanding what use-case Mongo was developed to target.
The issue is using a tool for the wrong reason
The fact of the matter is, all tools are good and all tools are bad. They’re just good in certain situations and bad in certain other situations. The issue then is if you ignore this fact and use tools without considering whether they fit a certain situation or not. And these reasons aren’t only for the execution environment. Sometimes the right reason to choose a tool is because of the community (X tool lets me hire lots of cheap programmers, or Y tool serves as a hiring signal to find the good developers), or the long term prospects (there exists a company that provides support for Z).
The solution is to voice out why you use a tool
In either writing down or voicing out the reasons for using a tool, you’ll end up with the confidence to proceed ahead. Since you’ll be cognizant of the pitfalls of your tool, you’ll be prepared when they pop up. Nothing is worst than being blind-sided.
Until you can voice out why you’re using a tool, you probably should reconsider choosing it for your upcoming project. The longer it takes for you to realize the error of your ways, the harder it will be for you and your team to move away from the tool. And unless you keep this issue in mind, you won’t notice until the point of no return. That is not the situation you want to be in. Your tool should assist you in reaching your goals, you shouldn’t have to fight with your tools in order to achieve them.
Shu is a father, husband, Python evangelist and open source enthusiast. He does freelance design and development as one-half of FreelanceDreams LLC. In his spare time he works for a local startup called RealGeeks[/author_info]