Polyglot programming in startup environments
Recently I founded a software development company called Ministry of Programming, and one of the topics that often goes through my head is the problem of overuse of polyglot programming, which is most often present in startups and it got extremely popular with the rise of micro-services.
Startups and micro-service architectures are an ideal ground for young programmers that want to make architectural decisions and experiment with programming language X to build feature Y because the language in question is “optimal” for Z.
With a lack of technical leadership and architectural control, an experimentation mentality, and a move-fast and break things approach, it is easy to end up having 17 languages in the same startup codebase, often split into micro-services. Of course you need Scala, Node, C++, Java and Go in the same code-base! Let’s throw a Python in the mix ;)
When polyglot is good
A polyglot approach might be good in a high-level architecture, and mixing different programming languages and technologies might be the right thing to do in many systems, especially in a micro-services architecture, but in a controlled fashion, based on non-functional requirements.
For example, combining SQL and NoSQL proved to be a good idea in many cases in the field. The idea of polyglot programming was popularized by Neal Ford and later Martin Fowler and others.
http://martinfowler.com/bliki/PolyglotPersistence.html
Polyglot programming is very inviting for programmers, because programmers always want to learn something new, and work with the hot new technology. There is a strong thirst for knowledge and experimentation in the industry.
However, polyglot programming is not a silver bullet, and mixing languages just because of preference and because of experimentation has a lot of downsides, so i want to present my own polyglot rules, hoping they could help you make the decision to add or not to add the “language du jour” into the mix.
7 Polyglot decision making rules
The deadliest polyglot sin is to introduce a programming language in the existing code-base out of personal preference, and without realistic argumentation.
How would you feel if you were studying in English for 1 year, and then Chinese was introduced just because of your teacher personal preference?
“Never introduce a new programming language in an existing code-base because of personal preference. Building software is a team effort. Globalize your code languages. Team cohesion is what matters the most.” — the first polyglot rule (a.k.a. language globalization rule)
Language globalization is so important, but many fail to honor this principle. I always remember the quote from Paul Graham as a reminder of the importance of the language globalization rule:
“If you’re writing a program that has to work very closely with a program written in a certain language, it might be a good idea to write the new program in the same language.” — Paul Graham
Language experience is also very important, and what often happens in startups is that young individuals with little experience use the language they know, and argue that it’s better than the existing code, because they built great apps in the past, or company X built product Y with it, and they have 100 million users.
Node.js is not good enough for your feature? you should be a damn good Node.js developer to make the decision to complement it with something else.
If you are not familiar with something, that doesn’t justify introducing more complexity.
“You must have production experience in the programming language you want to replace or complement with another one” — the second polyglot rule (a.k.a. relevant experience rule)
Polyglot decisions should be made based on realistic arguments, and not quora or stack-overflow discussions. C# is not the best language for your project just because Jon Skeet is using it.
A language should be selected based on it’s features and architectural benefits (e.g. Node.js for the Async IO features or C/C++ for algorithmic performance) and remember that everything starts from requirements, and the Yagni principle applies here as well.
“A decision to introduce a new programming language must be based on non-functional requirements, measurements or other relevant arguments, and not personal opinions.” — the third polyglot rule (a.k.a. relevant arguments rule)
Imitation is one of the biggest problem in tech today, and small teams are imitating big teams and big companies in every aspect, from interviewing to devops. Everyone imitates Facebook and Google. A good example of the imitation trend is the hype around no-sql, big-data and micro-services.
“Don’t imitate big software companies, but learn from them. Don’t be a copy-cat. Be yourself, and make smart decisions based on your own analysis and context. Simpler is better“ — the fourth polyglot rule (a.k.a. software imitation rule)
There are additional implications of introducing new programming languages in an existing organization, which are obvious when you are in a management position. It is not easy to hire a Go or Erlang developer these days, so introducing an exotic programming language could have a hiring/training cost for the business long-term, and it is a business risk to minimize the ability to hire.
A new programming language in an existing environment also limits the ability of other team members to contribute, and makes communication harder in the team.
And no, Haskell is not simple to learn for the average programmer, even if you think it is.
“Always think about the team and company, and especially about hiring and expanding the team. If you get hit by a bus someone needs to maintain your code, and most likely it will not be Steve Wozniak. Exotic is always more expensive”- the fifth polyglot rule (a.k.a. exotic hiring rule)
Multiple programming languages complicate builds and deployments, which means slower and complex delivery of the product. If you have Java, Node and Go in the same code-base you will have to think how to maintain all these languages in multiple environments at the same time. Docker is great, but it will not solve all your problems.
“Polyglot environments are harder to build, deploy and support. Don’t think just about development, but also about operations.” — the sixth polyglot rule (a.k.a. devops cost rule)
And last, but not least, think about the product of your startup, because you are building software for users, not an isolated algorithm on Hacker rank, and the programming language is just a tool to deliver software and the experience to the end-users, so don’t get overly attached.
“A programming language is just a tool to deliver software. Don’t be in a tight relationship with your screwdriver.”- the seventh polyglot rule (a.k.a. product-thinking rule)
Conclusion
Polyglot programming is an intriguing idea, and it makes sense in many scenarios, but context and a pragmatic approach is the key to success. Nothing is perfect.
Having a good CTO and architect in your startup could alleviate the pain of developing and operating polyglot environments, but the rules above still apply when making decisions.
I will finish my article with a quote from the article “Our Polyglot Nightmare” published on TechCrunch in 2014 that inspired me to write my article.
Ultimately, we are witnessing a collective action problem that is, frankly, impossible to fix. While there may be no “solution”, startups can avoid the polyglot issue by simply being deeply cognizant of exactly what languages they are committing resources to. Engineering managers should be incredibly cautious about introducing new languages into existing infrastructure, and also doubly cautious about moving from an existing popular language for one more on the frontier. Sometimes a performance hit may be worth a bit more cohesion on a team.
