New project, new tech stack?

What is the right language and framework for this new project?

What language and framework is your team most familiar with?

I guess… most of us have worked on Java/Spring projects…

Then those are the right technologies to use.

What about Ruby and Rails, though? Aren't you a big fan of those?

Is your team a big fan of them?

Well, no…

Then it's not the right choice for this project.

Wait, are you saying that we should always just use what we are familiar with?

Almost always.

What's an exception?

Some domains have strongly converged on a particular tech stack. If there is an overwhelmingly better ecosystem for the kind of work you are doing, the it may be worth it to take the productivity hit of getting up to speed on a new stack and its accompanying idiosyncrasies and idioms.

Can you give me an example?

Well, a lot of scientific work is done in Python. So the ecosystem of science tools and libraries is particularly mature, and there are a lot of people who can help you if you get stuck. Also, a lot of scientists have used some Python, so if they are your users, choosing Python may give you a leg up working with them.

What about scaling issues, though? Wouldn't we be better off choosing Go or Elixir?

I don't know. Would you? Do you have enough information right now to be certain that the types of scaling issues you are going to run into are going to be the type that Go or Elixir would make a crucial difference to your project's success?

_I don't know… _

Do you have confidence that your team will design a Go or Elixir system in a way that it will benefit from those language's strengths when the time comes? What did your team's first_ _ Java/Spring system look like, architecturally speaking?

Oof, I see your point. But… it's just that some of the team members have been playing with Elixir lately, and they've been really impressed with it.

Ah! I understand now. Your team is experiencing Tech Fatigue.

What?

Your developers have been using Java and Spring for years, and they are bored. They are watching people give talks about other languages and frameworks and different approaches to problems, and they are discontent.

So you're saying we're just chasing a new shiny object?

Yep. And you're hoping I'll give you a solid technical justification to pursue that shininess.

Ouch. So should we just suck it up and use what we know?

No!

Programmers are creatives. Creatives need new media and new constraints to get their juices flowing. New languages and tools can help developers break out of their creative ruts, and regain excitement for their work.

Wait… so should we go ahead with new tech after all?

Yeah! I say go for it. But! Be honest with yourselves. You're not doing this because you know it's the right choice architecturally. You're not addressing a technical deficiency. You're addressing an enthusiasm gap.

And for developers, enthusiasm is crucial! We don't do good work when we're bored.

But what if it doesn't work out after all? What if we run into unforeseen issues with these unfamiliar technologies?

There's a good chance you will. That's why you should time-box your experiment with new languages or frameworks. Schedule regular check-ins and retrospectives to ask: are we “getting this”?

Are we feeling competent and confident? Or are we spinning our wheels on questions about the “right” way to structure things in this unfamiliar stack?

Are we delivering stories? Or do we keep re-writing the same ones over and over?

When we get stuck, are we finding the help we need?

Are the developers on the team who were dubious of this technology warming to it? Or are they increasingly frustrated?

Set a decision date somewhere between three and six months out. Get together and decide as a team whether to move forward with this new stack, or whether to chalk it up to research and use something you understand better.

It seems like it would be pretty demoralizing to throw all that work away.

It could be. But you'll probably find that even if you do, the break and the fresh perspectives you've explored will give your team some new energy that they can apply to their old familiar stack. And they'll have a newfound appreciation for just how productive they are with the tools they are comfortable with.