Introducing a New Language

By AJ Foster -
8 minutes - 1525 words

At Pluralsight, we have a polyglot developer team in which individual teams can introduce new technologies. This is not a post about when to introduce a new technology into an organization, however. Hopefully the organization has a plan for managing the proliferation of technologies and adheres to it. Instead, let’s talk about the next step: introducing the new technology.

As an example technology, we can talk about Elixir: a functional programming language that we’ve begun to use in a few new bounded contexts at Pluralsight. It provides a human-friendly syntax in the functional programming paradigm with a battle-tested concurrency model. If you’re interested in learning a new language, some additional resources are listed at the end of this post.

At the time of writing, Elixir is not a mainstream language at Pluralsight. It could become one, however, so let’s talk about how to get there.

Potential Hurdles

We don’t yet know what the major hurdles will be to achieve widespread adoption of the language within the organization. We can make an educated guess, however, and attempt to address those issues head-on.

Technological: Short Term

Various documents throughout time have asked similar questions when addressing the introduction of a new technology within our organization:

  • What is the technical limitation you’re currently encountering? Or in other words, what are you experiencing that has led you to seek a solution? Give a detailed example.
  • What are you trying to do? Articulate your objectives using absolutely no jargon.
  • How is it done today, and what are the limits of current practice?

Although these questions have been answered for the specific contexts where we began to use Elixir, they will continue to be asked any time we advocate for the language to be used in a new context. Having precise answers for these questions can be difficult, especially when referencing processes and patterns from a paradigm that may be unfamiliar to some.

Tentative Plan: In these discussions, I would focus on the aspects of the technology which have the greatest effect on the capabilities of our product and the experience of our users. These might not be the headline features that the technology uses to market itself among developers. In Elixir, for example, we might focus on the real-time collaboration and feedback features enabled by the concurrency model. Overall, these discussions should focus on the business and on the customer rather than developers.

As we address new contexts, we find out if these aspects of the technology continue to warrant its use.

Technological: Long Term

While we expect that the questions above will continue to arise for various contexts, there is more to the technological story of introducing a language. Every technology, especially a programming language, brings consequences to the way we write code. Although we can’t account for individual tastes, we can observe the path provided for developers trying to use it.

Tentative Plan: In these discussions, I would focus on the aspects of the technology that pay quantifiable (or nearly quantifiable) benefits over a long period of time.

For example:

  • Does the technology have a particular set of features that improve developer speed and happiness?
  • Does the technology make maintenance and security fixes easier over time compared to alternatives?
  • Does the technology have features that make errors less frequent or easily detected?
  • Does the technology operate well with the organization’s existing infrastructure?

As more individuals try the technology and discover its utility, we find out if these aspects keep developers interested in using it.

Social: Exposure

One major apprehension when introducing any new technology in an organization is when folks are mostly or completely unfamiliar with it. Using a term or referencing a language that someone hasn’t even heard of can be jarring.

Tentative Plan: There are several avenues by which we can make the vocabulary surrounding a technology familiar to a large number of people:

  1. Pluralsight has a recurring meeting where folks share things they’ve learned. As we learn about the new technology while implementing it in the first few contexts, the lightning talks at this meeting are a great opportunity to present. The five minute time limit allows us to quickly mention a small challenge and how we tackled it — all while using relevant terms.
  2. We also have a recurring Architecture Guild where new technologies are discussed all the time. In this meeting, it’s more likely that we would make a larger presentation about our experience creating a new context or feature from start to finish. Attendance includes representation from many teams, so this presentation is a valuable chance to expose folks to the technology and advocate for its use.

If successful, these efforts will inject relevant terms into the organizational zeitgeist.

Social: Resources

If individuals are interested in learning more, it may be difficult to find resources relevant to the use of the new technology at Pluralsight. Using a new language as an example, we have a collection of shared libraries in C# and Node.js which make interfacing with Pluralsight’s shared systems easier. There are also plenty of contexts which can serve as examples of using these tools. This adds up to a relative ease by which teams can get started with one of these languages in a new context.

Tentative Plan: To help address this deficit, we can attempt the following:

  1. Create analogues of shared-services libraries. Specifically, the development of these libraries should focus on using idiomatic code and documenting architectural decisions. Feature parity is less of a concern at the outset. Each codebase can serve as a demonstration of problem solving with the new technology.
  2. Provide written documentation about how to get started — specifically at this organization. Although there may be wonderful resources elsewhere for getting started, these documents should focus on solving the particular problems we face at Pluralsight. Using familiar language and referencing common problems can go a long way to lowering perceived barriers to entry.

In general, the goal is to make the tech approachable for any team who wants to try it out.

Social: Deeper Knowledge

Although all of the above efforts are important, they don’t necessarily ensure that there is a large corpus of potential contributors to contexts using the new language, framework, platform, or tool. No technology can survive in an organization if its knowledge leaders are confined to one area of the company.

Tentative Plan: We want to create individuals who can further evangelize and provide leadership when teams ultimately run into difficult problems. This is by far the slowest process, but it can be done:

  1. Host workshops for developers to learn the technology and its patterns. Attendees can range from those casually interested in learning something new to those seriously considering it for their daily work. These workshops should focus on depth of knowledge, preferring discussions of architecture to a complete survey of syntax or features. Everyone involved is already a software developer and capable of reading documentation.
  2. Host smaller problem solving sessions for developers. Code kata are great ways to gain familiarity and comfort, and we can always source challenges from real issues that teams face.

These sessions have the opportunity to drive home the long-term technical benefits. In the end, we will hopefully find that we can create all of the talent we need rather than hiring for it specifically.

Pre-mortem

Let’s imagine for a moment that our efforts to introduce the technology fail. In a pre-mortem exercise we ask ourselves, “Why did it fail to achieve widespread adoption?” Here are some potential answers:

  • We didn’t do the things listed above.
  • Despite our efforts, individuals simply were not interested in learning a new technology.
  • It failed to address some fundamental needs of our business.
  • A core contingent of tech leaders left the company or gave up on evangelizing it.

We certainly hope that these things don’t happen, but by thinking about them, we can maximize our chances of success.

Conclusion

It remains to be seen how the use of Elixir grows in Pluralsight. We imagine that we’ll need to address:

  • From a technical perspective, why should we use this language right now, for this particular context?
  • From a technical perspective, why should we continue to use this language in the long term?
  • How do we give individuals exposure to the relevant terminology around the language?
  • How do we ensure there are ample resources to get started using the language in our organization?
  • How do we create leaders in the technology to ensure it remains viable in the long-term?

Whether things go well or not, we’ll learn a lot about introducing a new technology over the next few years.

Additional Resources for Introducing a Technology:

Additional Resources for Elixir:

Categories: practices
Tags: programming languages, continuous improvement