Large organization, different teams, unique tech stack or different ones?

Question

This is a difficult question that can involve many people, it is a real scenario and can have real consequences.

A big organization with about 100 developers, working on different teams. The teams work with different front-end technologies, maintaining different products for the same company.

One team has experience with Angular, for some years. They are good at that. But the company choose to use React for all the other projects, and want this team to use React too.

Is this a good practice? to force a team to work with a desired stack?

What is better for a company? - Let developers choose the stack, and have different technologies - Let the "architects" or the company choose a stack for the company and have a single technology

I know some of you will say that developers should choose the stack because they know the right tool for the right problem. But lets not use this argument please. Let's say "Developers use the tool they know", in this case both tools are similar, with both of them one can satisfy the same needs.. And i am just referring to Angular and React. I don't talk about back-end or other things.

There are some good reasons to make all the teams use the same tech stack: market adoption, sharing code base, unifying technologies. This makes sense. But, forcing a team that is proficient in the other stack to change... Does that make sense? To throw that knowledge and work to the trash?

Answer 1

Prescribing specific technologies is pretty low on my priority list, personally.

Technology choices should be made based on a list of criteria, including

• Meeting design goals
• Cost
• Maturity, availability of a documentation and a community
• Development team preference
• Availability of in-house developer experience
• Alignment with architectural goals and vision

It's not unreasonable to strive to have a larger pool of developers experienced in one technology across teams. But it's only one factor. Most of the time I see these discussions go awry because design goals haven't even been set and it's impossible to make a rational decision.

Answer 2

You mention two ways:

1. Let developers choose the stack, and have different technologies (ignoring architect/company reasons).
2. Let the "architects" or the company choose a stack for the company and have a single technology (ignoring what developers want).

But there are other ways. For example,

3. Developers could listen and agree to reasons that architect has (f.e. developers could easily migrate between projects and/or go to vacation faster when all projects are on same stack).
4. Company takes into account what and why developers want to keep old stack. And, for example, hire another team to create new version, keep this team for year while new version is created and then fire old team.

Also please note that what is good for company (hire new team and fire old one) isn't necessary would be good for developers and vice versa. Probably it's better for both sides just divorce each other.

Answer 3

Ultimately this is a question for management, and it can summed up in a single calculation.

Do the advantages of sharing a tech stack outweigh the cost of lost productivity on the teams that have to switch?

I would argue that the main skills of a programmer are not language/stack specific. I imagine most programmers have had to learn new languages/tech stacks during their careers. So having to switch should not be a big deal in itself.

The problem arises when management misjudges this calculation, and it's rarely the time needed for developers to learn the new stack that is the problem. Some common hiccups are.

1. Overoptimistic projections of the benefits of the new stack. Shiny new languages and frameworks can be easy to fall for, and the pitfalls of them may not be evident until several years later. At that point applications are large, may be maintained by programmers who did not originally write the code, and the inevitable new set of issues with the no longer shiny technology are apparent. It may turn out that even after everyone has expertise in the new framework, developers are not really any more efficient.

   Alternatively, the stack may be a poor choice for some types of applications that the teams were forced to switch to. Here is one area where management should listen to programmer pushback, and take that into account when weighing the benefits. But that's unlikely to be a factor for Angular to React.

2. Underestimating the true costs of the switch. Training the programmers is likely the easy part. What is hard to estimate is how long it will take to port company specific standard libraries, set up configuration, tools, and infrastructure (if needed), and port or update legacy software to use the new stack. Be especially weary if its decided to rewrite everything, that takes a long time even for developers experienced in the language that is being used.

There are definitely cases where trying to focus development to a single/small set of technologies is worth the effort. But there are a lot of pitfalls that can prevent such a change from being successful.

Answer 4

The company should never prescribe the technology choice that developers use. This will cause resentment if decisions are made by one person outside the team and most of the team ended up being force to work on the project don't like the chosen tech stack. You may start losing heads.

Instead, let the team decide, but slightly stack your odds so the team are more likely to end up with conclusion that you prefer.

If they ended up still choosing the other way around, then that is probably actually a significantly better choice, so in that case you should yield to their expertise.

Choosing a single technology stack isn't without its problems. If you do it to an extreme, it can make hiring harder because it restricts the size of your talent pool that you're hiring from. A too varied tech stack can also cause its problems as it makes your developer resources much less interchangeable.