Adopting a New Programming Language (or Tech Stack)

A question came up recently in a discussion group I frequent concerning best practices for adopting a new programing language. The scenario presented centered around a well-established, mid-sized company. All of their code was written in a single programming language, but they were interested in adding another language for a variety of reasons.

I had a few suggestions on the topic, which apply equally-well to companies that are adopting new technologies (ex: AI) or technology stacks.

1. Decide who makes decisions

Everyone who works in engineering will likely suggest their favorite language. Decision by committee will become untenable as choices multiply: don't be surprised at how quickly religious wars will start! Identifying a, hopefully small, number of decision-makers early is the only way to stay sane. Ideally, you'll have a small (2-4 people?) group that represents a variety of perspectives making decisions, rather than a unilateral decision-maker.

2. Pick a language that is already well-established for your use case!

A programming language (or technology stack) might be great, but if doesn't support your use-case well it probably isn't the right choice: you'll have difficulty locating tutorials for your use-case, you may have to build infrastructure yourself, you might have to fix bugs in existing use-case specific infra/libraries that haven't matured, etc. Ideally, you want to select a language or tech stack that works well for your current use-case and also has enough breadth and depth to support future use-cases.

3. Build some prototypes using your top 2-3 choices before making a decision

You want to build something small enough that it doesn't require a major effort, but big enough that you're likely to run into common problems/frustrations. Projects should take a minimum or 1-2 weeks; longer if you can afford it. Afterwards, do an honest post-mortem and see how each of your choices faired:

• What was easy?
• What was frustrating?
• What problems did you run into with tooling?
• Could you debug and correct problems efficiently?

Ideally, your post-mortem should evaluate the projects on criteria that you'd previously established during the selection process.

4. Start small!

When adopting new programming languages, technologies, and tech stacks you may not want to open the floodgates and allow everyone in the company to start using your new choice on Day #1. Ideally, you'd put a small team of senior engineers on the first project or two and let them figure out workflows, tooling, best practices, etc. which you then rollout to the rest of the company. This is a chance to ensure that your tech really works and isn't missing any major features (ex: easy networking, predictable concurrency, efficient DB communication, logging, etc).

4a. Plan for a retrospective

After your first project or two, you should do a retrospective to ensure that the choice you've made is still the right one. Build this into your rollout plans so everyone is aware that it will happen! If it ends up that you're trying to pound a square peg into a round hole, this is the time to realize that and go back to the drawing board.

5. You may have to roll your own training and tutorials

Over the last year, there seems to be an explosion of garbage tutorials. We may or may not have AI chatbots to thank for that, but the result is that it can be difficult to on-board people to new technology: there's just too much tutorial content available and much of it is useless or downright incorrect. At the very least, you'll want to put together your own on-boarding curriculum that references "known good" resources (ex:read Blog post #1, then watch YouTube video #2, then work through tutorial #3, etc). You may need to supplement existing online materials with (hopefully brief) training that's specific to your company, your use-case, your company-specific tooling, etc.

6. Figure out how you're going to handle code reviews

Particularly people start coding in a new language, they rarely write code that's idiomatic to the new language. In most cases, they'll spend some amount of time writing code that's idiomatic for their pervious programming language using the syntax of the new language. The same is true when adopting new APIs and technologies: you initial implementations are rarely optimal. Left unchecked, this can lead to mountains of tech debt. If you care about that, you might want to establish a pool of designated code reviewers or experts who can help bootstrap teams onto the new language or technology. Rollout will be slower, but the overall results may be better than a free-for-all rollout.