Maintaining Multiple Code Stacks: Why, When and How You Should Do It

One of the great debates among programmers is whether a company should write and maintain all their code in the same language. (Another great debate is whether The Bachelor television franchise represents a post-modernist view of romance but we’ll get to that in another article…)

What is Multiple Stack?

Let’s start with why this coding question even exists in the first place. As a company grows, it’s product invariably adds new features that require new technologies or it may acquire other companies whose products are written in a different language and –voila!—it suddenly has multiple code stacks.

When this occurs, the first instinct from many of your tech folks will be to rewrite all the code in the same language. But our experience across a huge range of customers shows that this is an opinion based more in aesthetics than in practicality. For example, if your company buys an office building that has wooden desks and wooden chairs but the firm’s headquarters has metal desks and chairs, there would be no practical reason to replace the wooden desks. It would just add an expense that doesn’t provide any value to customers. Code stacks are not Starbucks, they don’t need to maintain a visual brand.

Or as a former CTO boss once yelled at us early in our tech career when we argued for a single language, “You aren’t a supermodel like Heidi Klum! We don’t get paid based on the beauty of our code, we get paid based on how well our code works.”

Time for rewriting the Code

Some of your developers will offer a reasonable argument for rewriting the code: it reduces the overhead of maintaining multiple stacks since everyone on the team knows how to read and write it. But it usually takes 6-12 months for a typical engineer to be productive within a new code base even if it’s written in the language in which she/he specializes in. So if you aren’t saving much time or energy by rewriting it, why endure the pain and suffering?

But the most expensive part of rewriting the code is the loss of institutional knowledge around the business problem that the code is trying to solve. Every code base is a specialized tool created to solve a particular set of problems for its users and that knowledge takes years to build (and it compounds over time). In other words, the coders who work on it aren’t just great at programming, they are experts in the business problem. Rewrite the code into a single stack and suddenly you wiped out years of deep domain expertise in the name of beautifying your internal code. That is an expensive exercise.

So now that we understand that managing multiple code stacks is actually a smart decision in many cases, what is the best way to go about it?

How to effectively Manage Multiple Stacks?

To effectively manage multiple stacks, start with a modern modular structure where the code base is a collection of micro services which interact with each other through APIs (since APIs are code base agnostic). Next, separate your development organization into teams specializing in different code bases and business problems supporting their own micro services. This will add a little overhead to your overall team, but it will likely save you a ton of time in the short and long run, because you are not constantly redoing something that already works just fine.

And if your team still feels as though they must write on a common language, at least don’t rewrite everything all at once. Simply freeze the actual code base that you seek to rewrite and don’t touch it until it starts to break, can’t effectively scale or your end users demand more features. Then do the upgrade on the new code base from there.

So the next time you find yourself in a holy war between single-stack adherents vs. multiple-stack believers, just remember that in the majority of cases, you are unfortunately not Heidi Klum…

Want to learn more about code stack decision-making or discuss a particular challenge you are facing? We are always here to help at info@turnkeystaffing.com or 310-699-6884.