Choosing The Right Tool For The Job


It has occurred to me recently that some tools and languages are better than others when starting a project (duh). For example, I now prefer to use rails than node.js for a project’s phase 1. Now, the reason for this is that even if Node might be faster(dunno that it is or not; just for argument’s sake) and that rails might offer a lot more “magic” (which some like and others don’t), rails has many mature tools to let a developer get a phase one built more quickly (Node.js might have similar tools built for it, but one can argue that Rail’s are more mature). And, obviously with a phase one, you can better know what a phase two will look like.
I’m not advocating for always choosing the tools that are faster. Making decisions this way can lead to more technical debt. There are many tools that take a long time to learn, but the payoff is worth it in the end. For example, something like Kubernetes might take a good while to learn and get good with. However, the benefits are huge. You would then have a powerful tool for managing distributed systems. However, your new product probably doesn’t need to be distributed yet (and it might never need to be). Wasting time on this at the start is wasting time and money that you might need to make your product amazing. Of course, I’m talking about building MVPs.
Another major consideration is using what you already know. If you are trying to build something, you probably shouldn’t always be looking at the newest tool/language on the block (looking at you javascript frameworks). Sometimes what you know now is the quickest tool for the job because you don’t have to spend your new product’s time learning a new tool or language. Plus, not having to learn something major would be one less road block to having your product out there in the hands of real users.

Thanks for reading,

John

Leave a Reply

Your email address will not be published. Required fields are marked *