Most software companies don’t ever get to see a steady state, where the core product has been built, the rate of innovation decreases, and maintenance and minor improvements become the primary workload. In this world, priorities shift from figuring out the product, to ensuring customers are happy and keeping the lights on.
Recently, I came across a tweet that alluded to big tech companies constantly rewriting their systems (think mobile and web applications), as a means of job creation or lack of meaningful work. Good jokes always have an element of truth though, so let’s think about that for a bit.
Usually, a system evolves over time to handle more use cases and bigger workloads, and serve a more global audience in the case of social networks. Over the same period of time, teams are created, reshaped, terminated, and shuffled. The organization on day one is completely different from the organization on day 365 which again is completely different from the organization in years 2, 5, 10, and so on.
At Hygraph, we originally started with JavaScript-based services, then adopted TypeScript, and then slowly started re-building existing services and starting new backend services using Go for performance reasons. We evaluated other choices such as Rust but decided that it would be best to choose a language everybody can get onboarded to within the short to medium term, even people working on different parts of the stack like frontend engineers. Go is a simple language that is mostly fast, with great tooling and a mature ecosystem.
Over that time, engineering management has to continue building the product, helping the company to enter new markets, keep bigger customers satisfied by providing reliable services, and fixing issues along the way.
What we don’t think of, however, is that companies must remain attractive to new hires. Chances are, that your initial team has mostly departed after 3 to 5 years. Some people may still work at the company, in managing roles or positions created just for them, but the majority of engineers will be new. This cycle repeats continuously, so 50% of the company may have joined in the past 12 months, every year (which is the case when the company is growing steadily, in a downturn hiring slows or freezes altogether).
So keeping that in mind, the tech stack must evolve as well. Newer hires have different skill sets, new technologies might be on the rise. There’s nothing bad about a Rails monolith, but it’ll be much more expensive and harder to find developers who are proficient in that area, compared to the JavaScript ecosystem, for example.
In the end, the stack should fit the objectives brought in to serve customers (performance, reliability) but also to retain and attract people (technology used in other companies, tools that help you advance in your career, etc.). If we think about our chosen tools from this angle, continuously improving and rebuilding services using tools and languages that are the best fit then starts to make sense.
On the flip side, there will be people in your organization who oppose change, and sometimes, without objective reasons. It’s good to discuss this on non-emotional grounds, making sure everyone understands why keeping or changing tools in an organization is necessary to remain attractive or increase team performance.
Building Anzu, I chose a similar stack, using Node.js and TypeScript to move fast, and building parts of the backend using Go for reliability reasons. For the frontend, we chose to use React and TypeScript because of the sheer size of the ecosystem and my experience using React. My co-founder Tim had mostly used Angular up to that point, so using a different stack required a higher effort on his end, but the advantages React would offer us down the road (as well as allowing both of us to work together easily) convinced us to make this decision and I have a huge deal of respect for Tim to make this compromise for the sake of velocity.
Of course, changing the stack should not be an end in itself, but rather a planned activity that is strategically executed. That way, it’s closer to reducing technical debt (or building technical wealth, whichever way you prefer to call it).
So to conclude, if your interns are choosing a new framework just because they have nothing else to do, set them up with better tasks, but stop and think about why they choose their tools. Maybe you’ll learn something new along the way, which could help you with hiring and retention.