OK so I understand you think teams should stick to the tech stack they have the most familiarity with.
Yes, under most circumstances.
Riddle me this though: I have a freshly-assembled team. One dev is fresh off a Rails bootcamp. One is a veteran Java developer. One has spent most of their time with PHP and Laravel. And the last one is a Node/Express fan.
Ah, diverse experience! Excellent.
Yeah, but what tech stack should we choose for our project?
Oh, I have a tool for that. Let me check my pockets… yep, here it is.
This is a twenty-sided die.
Yep!
Are you saying we should pick a tech stack at random?!
Yes, I am.
_Surely we should have a process where the team comes up with criteria that matter to us, and ranks the alternatives as objectively as possible? _
You could do that. But then you'll have two new problems.
Oh? What are they?
First off, you'll be kicking off your project with unfounded confidence that you picked the “right” tools for the job. You'll probably even write a blog post all about how you chose, and why after much discussion you are confident that you picked the best possible option for your project. As a result, your whole team will be emotionally invested in the “rightness” of your choice. If you run into serious, showstopper issues early on, you'll be inclined to push through them instead of stepping back and reevaluating your choice.
Hm… you're probably right about that blog post. You said there are two problems, what's the second?
In theory, you'll create a process for objectively choosing a language and framework. In practice, the loudest person on the team with with the strongest loyalty to their tools of choice is likely to dominate the conversation. They'll campaign hard for their preference, and they will come up with counterpoints to any objections.
_Yeah, I'm pretty sure I know already who that will be… _
As a result, at the start of your project you'll build an unhealthy dynamic into one of your founding decisions.
You think making a random choice is a better alternative?
I think if you choose at random among equally viable alternatives, you won't be tempted to rationalize your decision as “correct”. You won't be as emotionally invested in your stack. And you'll avoid an early dynamic of dominance-by-zealotry.
OK, one last question: I'm an obviously fictional interlocuter with a transparently contrived problem. A real software team is unlikely to have that diverse a set of backgrounds. Why even invent me?
Yeah, fair enough. Here's the thing: developers have a tendency to mythologize their tech decisions. Often, these mythologies center around how supposedly “objective” the choice was. This obscures the subjective, human elements in the decision. Sometimes, it elevates the choice to the level of an article of faith.
A random choice of stack might not be the ideal choice for a given team and project. But I'd rather work with someone whose answer to the question “why did you choose X” is a shrug, than someone who is wedded-to and defensive about their tools.
Top comments (1)
I think this is one of the scariest reads that I got here. There are good reasons that there is a field called Software Architecture.
The Conclusion that I get from your post is that you never did anything that was running longer than a year. But I will give you some value as you think that a framework and the language is the problem I answered on your other post a new Tech Stack.