How will a team ever know the best suited language, framework or tool to pick if they’ve never tried it out before? I would say it is extremely difficult to know the best thing to choose, other than the ones already in our comfort zone.David Vujic, LinkedIn
This question is great because it illuminates a very common viewpoint in software development, one that hurts teams and software deliver-ability without us even realizing it.
This question puts the language’s needs before the team’s needs, or more correctly, the needs of a human being to grow and learn before the needs of the specific team or the business context that spawns the question of language choice.
This isn’t a value judgment, it’s only natural — human beings, as a truism, must feel a measure of growth or we would stagnate mentally and emotionally and wither away.
Put another way, the question asker is positing that there exists a better language or framework independent of the team’s knowledge, the business, social, and financial context, and that a team should choose that language over something that they already know.
Does that sound absurd to you? I mean, it does when I write it that way. The language and the framework is a tool. It is a means to express the idea of the software into reality.
The language and the framework should be subservient to the team. The language and framework doesn’t drive the goal of the software, nor should it! The team picks the language and framework they’re most familiar with that will solve the problem at hand. The ‘best’ choice for the team becomes an intersection of what they know and what their needs are.
There’s a related idea to this, that a team has a few ‘innovation tokens‘ to spend, and once spent the team should choose ‘boring technology’ that they already know. I argue that innovation tokens are really innovation anchors of an unknown size. They may either weigh you down or they may have no negative impact on development altogether, but you won’t know until you use them. Depending on your comfort with risk and your business’ risk tolerance, this may be an unacceptable risk, or it may be just another Tuesday.
The best suited language or framework does not exist independently of your team’s context. ‘best’ is an internal comparison for your team to make; not a worldwide Olympic ranking of software languages and frameworks. If you don’t know a language or framework, and your team doesn’t have a good understanding of a language or framework, then there’s no possible way it could ever be the best choice for your team — even if it’s the ‘best’ choice for another team that wrote about it on the internet!
To bring it back to the overall theme:
Software tools (like languages and frameworks) and processes are ‘best’ only internally to a team and a specific context. The tools and practices have to align to the team’s culture, its current skill level, the business needs, business culture, financial constraints, and technical and regulatory constraints of the development and deployment environments. There is no such thing as a ‘best’ tool or process that will apply to all teams, everywhere, always.