How to Move 100 Developers From JavaScript to TypeScript and Stay Alive
During one of my first days as a new developer at Natural Intelligence, I was requested to write a microservice that interfaced with some external APIs and required some complicated logic. The microservice needed proper software design and architectural planning. Always keen for a new challenge, I was very excited about the mission.
After I presented the High-Level Design document to the relevant parties, I felt like something was missing — a comprehensive examination of all the requirements made me ask myself: “Is JavaScript adequately robust to implement this complex software design?”
Finding the answer to this question took me on a wonderful journey in which I successfully employed a method of implementing a big change in a dynamic organization.
Five Stages Of Change
One of the models of creating a change is the Transtheoretical Model, which is also known by the term “Five stages of change.” It was suggested in the ’70s by James O. Prochaska and Carlo Di Clemente. The five stages of change, as they suggested, express the inner motivation for a concrete change.
I. Winds of Change
The first stage is the “Precontemplation” stage. This is when we are not yet aware the need for change exists, however, there is an external demand to make it happen. I decided to look for a better solution and find the right combination between a dynamic language and a strict one. TypeScript seemed like the optimal choice. From that moment, an incredible journey began — a journey in which I decided to make the entire R&D team understand why we should embrace TypeScript.
After conducting extensive research, I found some clear answers about why TypeScript is the optimal language. When dealing with large-scale applications as we do in Natural Intelligence — type-safety and the use of interfaces make refactoring much easier and prevent developers from unintentionally breaking things while moving in and out of the codebase. The larger the codebase grows, the more necessary it is to have formal and verifiable contracts between different parts of the code. If you want to read more about the reasons why Natural Intelligence chose TypeScript, you can jump ahead to the article where I explain it in more detail.
Sometimes it’s hard to put feelings into words, for me the idea of moving into TypeScript was very exciting. But it’s important not to involve feelings with the actual needs of the company.
So in order to prove to myself and to the stakeholders that it’s not only a love story, I convened a meeting with Natural Intelligence’s tech leads, architects, and team-leaders. I had to be very precise about the reasons why I championed this idea. Well, It seemed like I did a good job! When I asked them to give Typescript a chance and let me write a demo app — I was pleasantly surprised — some even chose to join my effort. For me, it was exciting, because now I had some partners walking on this journey with me.
II. Setting a clear path
The second stage in the model, “Contemplation” is the most critical. During this stage, motivation for change is brought to attention, even if it’s small at this point. Here begins the process of option deliberation.
When talking about such a tremendous transformation between technologies, it is essential to understand two main driving forces in any industry: time and money. Naturally, the key members of the organization wanted to know what positive change the shift to TypeScript would bring the company. My partners and I had to speak their language in dollars and time. We gave the key members estimates on how long the process would last, what the steps were, as well as the financial implications.
The transformation could be lengthy. It had to be measured by two parameters, the first one being the number of developers. The second one being the developers’ readiness to learn and implement the new technology. This latter factor made it crucial to ensure the developers understand the benefits and the motivation for change.
Besides time and money, we had to consider the risks associated with the shift. Our main concern was that developers would not be open to the new technology and consequently refuse to accept this challenge.
We understood that to be successful in our feat, we needed to transparently discuss the change with everyone and be open to their concerns towards the change. We needed to seamlessly transfer to TypeScript without adding a burden to the developers.
III. Making a Decision
In the third stage, a decision is made, the motivation rises, and there is an intention to take action. Decision-making is an integral part of modern management and sometimes critical because it may affect a lot of employees, this is the reason why the mission was so important. For the managers to make a call, we had to think deeply about the pros and cons of the alternatives, the trade-offs, and mainly about the careful steps we’d have to take to make the transformation correctly.
The process of decision-making is different in every organization; in ours, the process included presentations (and some top rhetorical skills) in front of the senior managers, including the CTO, VP R&D, and other technological leaders. We had to present some use-cases and the demo we drafted.
Having partners proved itself every step of the way, but especially when researching together. Finally, our hard work paid off. The moment we all waited for had come! It was money time. In a meeting with almost 20 people, the CTO made his conclusions and said that “change is inevitable”, and this was the moment we understood that a new beginning had come.
IV. Action! — Planning the Roadmap
The fourth stage in the model is the “Action” stage. For us, it meant we had to create a roadmap and to start planning the migration steps. There were a lot of factors to take into account and many decisions to make.
The first decision was which transpiler we should use. There were two options — using Babel transpiler with TypeScript preset, or using the TypeScript classic compiler (TSC). Each one of them fits another architecture: Babel can be the right choice when practicing Monolith architecture because JavaScript and TypeScript files can be in the same project. TSC would be better when migrating all the application at once. Because we embrace microservices architecture, we chose TSC to transform each microservice at once fully.
The second one was that from now on, NPM packages would be written in TypeScript, and for the old packages, we’d add a declaration file, which wraps all the method signatures and interfaces and exports them so we can use them inside old JavaScript packages.
In terms of scalability and flexibility, TypeScript itself is not enough. We realized that the added value would be significant if we used a framework; this was our last decision. After a wide search, we discovered NestJS, it’s a powerful framework used to build scalable server-side applications. NestJS uses progressive JavaScript, is built with and fully supports TypeScript, and combines elements of OOP, Functional Programming, and Reactive Programming.
V. Future Plans
The fifth and final stage in the model is the “Maintenance” stage. We have to be sure the developers will keep the TypeScript code standards and will embrace the new technology; hence, from now on, all new microservices and NPM packages will be written in TypeScript.
Mostly I think the essence of the transition should be a mental one. We have to keep the developer’s belief in the form of type-safety and less flexible as we experience it in JavaScript.
And that’s why we also need a training program: we plan to start with code review sessions, where we will discuss the code in detail, accompanied by explanations. Then we will expand the program and design a full course about TypeScript. Another cool idea we thought about is to determine TypeScript “champions” — those are developers who are willing to help other developers and be a trustworthy source when help is needed.
Final Thoughts
The transformation process will probably take longer, but it’s taking shape over time, and it’s a beautiful thing to see co-workers joining and obtain the benefits of the transition. My partners and I learned that as in life — sometimes changes are essential, and an organization must know when to make them. I want to take this opportunity and say thank you to everyone who stood behind this fantastic process and believed in it the way I believed in it.
