There’s little question about it—when it comes to embedded systems programming languages, C is the reigning language. Over the last several decades, there have numerous attempts at a coup, but when the dust clears, the C programming language seems always to be the language left standing. In recent years, there have been rumblings once again about replacing C with other languages. Whether the would-be usurper is C++, Rust, or some different language, transitioning away from C can be fraught with issues and difficulties. This post will explore three tips for transitioning a development team away from C and into the modern age.

Tip #1 – Transition Incrementally

When the decision to change programming languages is made, teams often want to jump in and start developing using the new language immediately. Starting immediately is not a bad idea, but it’s essential to recognize that switching languages comes with unknowns that will likely cause current development projects to take longer and potentially cost more. So, rather than rushing in and switching 100% to the new language, transitioning incrementally can keep development moving while switching to the new language successfully.

For example, a team might find that their microcontroller has low-level libraries for interacting with hardware written in C. Rather than rewrite all these libraries in C++, developers can use C++ to create interfaces that call the existing C libraries. Developers will gain experience creating interfaces with C++ while preserving existing code and minimizing the time and cost to start using C++.

In general, a team should identify where the new programming language offers the most benefits for the time that will be invested and focus on using the new language in those areas. Over time, and as needed, developers can update their existing legacy code. However, teams that try to redo it all in one shot often set themselves up for failure.

Tip #2 – Test Developer Efficiency

Every developer has a proficiency level in using various programming languages. However, while a developer might get excited or push for a new programming language, that doesn’t mean they can sit down and start writing quality production code for that language. Therefore, before beginning the transition, managers must ensure that their developers are up to the task and have the skillset necessary to successfully use the new programming language.

Each developer should be tested to see how well they understand and can use the new programming language the team is adopting. I often recommend that only highly proficient developers start to use the new programming language during the early stages. In contrast, the other developers support those developers or handle maintenance activities. During this period, less proficient developers can take on small activities with the new language designed to help them improve their skillset while remaining productive to the team.

Tip #3 – Create a Training Plan

After testing developers to see how proficient they are in the new programming language, several developers will likely not have the desired skill set. So we don’t just throw these developers to the side but establish a training plan to help them come up to speed as quickly as possible.

A training plan can have many aspects. First, the plan might entail formal training in a classroom setting. The training could be contiguous, where the developers go away for a week, or an expert performs the training on-site. If the team is located near a university, having team members sign up for a course given throughout a semester can also make sense. I’ve found that courses that spread the learning out over a more extended period are more effective at transitioning skills to the developer. However, if the course must be done all at once, it’s a good idea to have a coach who can follow up and answer questions as they arise.

Next, beyond formal coursework, a wide range of resources should be integrated into a daily work routine. For example, the team and developers can leverage countless blogs, articles, videos, and books to become proficient. As part of the training plan, developers should spend at least 30 minutes every workday growing their new skillset. Disruptions, where they may go a week or more without using those skills, can slow down how quickly the team can transition to the new language.

Finally, part of the training plan should include hands-on practical experience. The preference would be to apply the new skills to the project at hand, but it may be necessary to assign throw-away projects designed to exercise the skillset.

Conclusions

Transitioning to a new programming language can be an exciting endeavor with many benefits. Leaping, though, should not be taken lightly. Incremental steps should be taken that are backed by a good training program that evaluates developers and puts in place a training plan for them. Many modern languages can either directly use C code or at least link to compiled C code. Teams can choose which areas of their code move to the new language immediately and which remain in C.

Leveraging a modern language beyond C can provide many benefits to developers and teams—just be careful about how you go about transitioning away from C.