I Almost Got Fired for Choosing React in Our Enterprise AppReact was supposed to ease our development. Instead, it created roadblocks

I Almost Got Fired for Choosing React in Our Enterprise App

React was supposed to ease our development. Instead, it created roadblocks

Razvan Dragomir

Photo by Samuel Bourke on Unsplash

It’s summer 2018. My boss, Adrian, asks me to join him in a Skype call with James, the CTO of a big Canadian company.

While getting to know each other, I find out that James is a smart guy with big ambition. His vision is to migrate a massive desktop WPF application to the web in the cloud.

I like his friendly attitude and I can tell that he is eager to collaborate with us. He already has a development partner in India, but they lack experience in building web applications.

Adrian and I follow the standard approach for this situation. We have a few more calls and then we start the discovery phase in which we try to grasp the big picture and find the non-functional requirements. These are the main points we should focus on:

A big application — more than 220 pages, most of which are maintenance screens and around 20% of which are highly customized.

Display large amounts of data, especially in grids with all kinds of features: grouping, column freezing, row expand, custom columns, you name it.

Modular architecture allowing multiple teams to work on the project at the same time.

Multi-year project. New features will be added over time.

No offline support is required.

Quick onboarding for new team members, especially for the .NET developers working on the old desktop application.

As an architect, my role is to create a technical proposal that contains the architecture details, approach, roadmap, guidelines, and most importantly, the technology stack that will be used.

James mentioned multiple times that he wants a future-proof technology, and he is not in favor of Angular because it has a bad reputation after AngularJS got deprecated.

I had already successfully implemented a few small and medium-sized projects using both Angular and React, so I am not really attached to any of them. I feel that either could do the job.

For this project, I pick React with Redux… which I will regret two years later.

We assign a team of three developers to work on the proof of concept, and after two months, it’s a success. Super-responsive user interface, blazing-fast build time, and high development speed. Everyone is happy.

Roadblock #1: .NET Developers Join the Team

After the proof of concept, it’s time for the developers from the client’s outsourcing team to join in. We hadn’t started the knowledge-sharing sessions yet and the CTO sends me an email saying, “Hey, Răzvan. We really have to meet tomorrow with my outsourcing team.”

We have that meeting and the technical lead ambushes me with questions and solutions:

“Where is the dependency injection? What do you mean by ‘There is no need for one?’ Here is one: InversifyJS!”

“Functional components? No, no, no. We don’t like them. Let’s use class components!”

“Why do these functions just hang around and why aren’t they encapsulated inside service classes to make them static?”

“Where is the Retry Policy for the API? Let’s implement one using PollyJS.”

“Why are file names dash-case when class names are PascalCase? It should reflect the class name, so from now on, we will name them SomePageComponent.tsx.”

And, the one that annoys me most: “How can I run it using Visual Studio and not Visual Studio Code?”

It‘s’ clear to me. They want to use the .NET guidelines and design patterns in React. I have seen this happen many times — developers who have a hard time adapting to the new technology’s way of doing things. So I am not afraid of getting into a debate about why those are unusual patterns for React.

But in this case, the CTO is backing his team, which is normal. He had known me for just two months, while he had been working with his team for many years. I have to make compromises and agree with their proposals.