I wrote a provocative post about team language choice, and one of the best questions I’ve gotten in reply is from David:
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.
Absolutely agree with this.
I saw a great talk at CodeOnTheBeach in 2019 by Mike Potts, that speaks about the importance of relying on collections of heuristics and skills, which he refers to as “the state of the art” – who you are today. It’s time-stamped and context-dependence.
Link here: https://www.youtube.com/watch?v=CWIJzypKux8
I think he breaks it down very well and uses great language. Treating this as a reminder to myself to pick up that language again.
Glad to see that my question have inspired you to write a blog post!
I am also surprised how you have interpreted it. Is picking a programming language that controversial?
From my experience as a member of a couple of teams, choosing a new programming language or a new way to work (like mob programming or Test Driven Development) haven’t really been a controversial thing. In retrospect, I cannot remember one single time we have said things like “we should have sticked with good old asp.net webforms” or something like that.
Even though at the time of choosing, there probably wasn’t an obvious straight line between the new cool tool the devs wanted to try out and the business needs. However, I think a lot of developers really care about how to maintain code, code quality and how to automate repetative (and boring) tasks. Long term, this will have an impact on the product and on the business.
Yes, new things can be painful. Learning a fresh new way of writing and packaging css, or switching mindset from OOP to functional can (and likely will) affect the productivity of the team at first. Long term, it most likely will be the opposite.
I think there is a huge risk of an Epic Fail if picking the best tool means “pick what we already know, even though it sucks, to build and release something super fast”.
What about experience with bad choices (yes, they exist, and yes they are absolute truths)? What about (license) costs involved? What about teams that ask for a standard set?
Yes, programming languages are tools, but so are shovels and spoons. If your team is only familiar with spoons and you have holes to dig, then actually the choice of tool did matter, and you shouldn’t have gone with the path of least resistance by allowing the team to dig with spoons.
I am reminded of Paul Graham’s article “Beating the Averages” which discusses the paradox of Blub, and imaginary “boring tool” language which is the path of least resistance for the team, yet brings a missed opportunity cost in ignoring the other superior tools.
I’d agree that there is no “best” language, but there are certainly some choices that are better or worse than others, and to completely ignore that in favour of the lowest common denominator is a bad idea, even if it’s a safe choice from a middle-management perspective in large companies that can more easily absorb waste and inefficiency.