Many times in our careers as software developers we tend to use the same known tools to do a completely new different project with new constraints.
Why do we tend to choose the same tools with small changes over and over again if we have the chance? Abraham Kaplan wrote in 1964 [1]:
I call it the law of the instrument, and it may be formulated as follows: Give a small boy a hammer, and he will find that everything he encounters needs pounding.
Two years later, in 1966, Maslow added [2]:
If all you have is a hammer, everything looks like a nail.
As humans we don’t change too much and principles like these, written more than 40 years ago, are still relevant to our industry.
In my opinion this is related to the comfort zone state where you don’t change anything to avoid risk. The problem with using the same tools every time you can is that you don’t have enough arguments to make a choice because you have nothing to compare to and is limiting your knowledge.
There are always other possibilities, but the important thing here is to keep looking for the best possible choice, even if we aren’t very familiar with it.
Sometimes you can’t make the best possible choice and that’s fine, imagine you don’t know anything about C++ and you choose that language because you have read it has a better performance. You are probably going to spend a lot of time just learning the language and your manager won’t be very happy about it. Sometimes it all comes down to make a choice that makes sense in your case not just the language or library you always use.
There are more examples of the law of the instrument, one of my favorite is RubyMotion, which claims this in its homepage:
RubyMotion is a revolutionary toolchain that lets you quickly develop and test native iOS and OS X applications for iPhone, iPad and Mac, all using the awesome Ruby language you know and love.
Yes, you might know Ruby but using a wrapper to avoid a native language like Objective-C or Swift without very clear advantages apart from using Ruby itself doesn’t sound very convincing to me.
Just to clarify this point, I think using the same language to wrap other native languages is not always a bad idea, the Xamarin project is a good solution because you can actually share the codebase in four different platforms (Android, iOS, Windows and Mac) and the language (C#) is more similar to the native ones.
In conclusion, the next time we face a new problem in a new context we should try to explore new tools, because we’ll find better ones to solve the problem, we can learn a lot with new technologies, the system will be much better and we can actually defend the decisions because we would have compared some approaches.
References
[1] Abraham Kaplan (1964). The Conduct of Inquiry: Methodology for Behavioral Science. San Francisco: Chandler Publishing Co. p. 28.
[2] Abraham H. Maslow (1966). The Psychology of Science. p. 15.