Over the course of the last couple of years, I’ve been working on a lot of different projects where we initially had to make some technology decisions on what development ecosystem to use. By development ecosystem I refer to the sum of programming language, IDE and API (libraries) needed. In most of the discussions it was typically a debate based on the individuals personal preferences and what they’ve used to work with, rather than a non-biased discussion based on what problem we’re trying to solve.
Personally I don’t think the best approach to select any specific implementation technology is to let it be based on personal preferences, albeit I do concur, that sometimes that will get you there faster. There’s a lot of factors that needs to be taken into consideration prior to selecting specific technologies. One of the more important things to take into consideration is the preferences of your customer base. E.g. trying to shove a Java based solution down the throat of a .NET fixated customer base or vice versa – isn’t the most sensible thing to do, or at least not the smartest. It may be easier to chose technology based on the preferences of your customer base. From a selling perspective, by doing so, you remove one obstacle in the sales or adoption cycle, whatever commercial model you’re using.
The next problem in the personal-bias-decision-process (PBDP) is that the decision process becomes based on the individual decisions makers personal bias and technology comfort zone. So rather than evaluating tools and technology in the context of the task, I’ve encountered and witnessed a fair amount, or more precise, I’ve predominately seen people doing it the other way around. They evaluate in the context of their comfort zone when it comes to technology and tools.
Personally I find this approach somewhat disturbing, as there’s a risk you end up utilizing the wrong tools for the wrong tasks – like a carpenter trying to use a chainsaw to create a replica of a renaissance chair. But what really throws me off, is that we as software engineers are obligated to propose the best tooling for the task to facilitate speed to market, customer adoption and fast feature turnaround.
We as engineers should always be looking for new and better ways to develop software, researching new technologies, tools and languages to keep track of what’s going on in our field, to be able to recommend the appropriate tools and technology for a given task. We should see an opportunity to use new tools as a way to broaden our experience rather than being hampered by our comfort zone.