This story is an interview with Marc Trabucato, Lead Engine Programmer at Ubisoft Montpellier.
Hi Marc, can you describe the project you’re working on at Ubisoft, and your mission there?I’ve worked at Ubisoft for 25 years now. I started as a developer and then became a software architect and trainer. About the context, the project involves the production of new technology, including a new game engine and new tools, for a new video game. The project started a few years ago, and the teams grew progressively to reach hundreds of developers distributed in several studios. I joined the project to help the teams until its completion and final steps, especially debugging and optimization. We had to produce the new technology using modern C++, not necessarily mastered by many engineers. My mission was to train our engineers on these topics and write documentation, set tools and methods to support this.
What were the challenges to address?We work on a proprietary technology that is still complex to use. This creates a significant barrier to entry, especially for junior programmers, as this technology uses specific patterns and tricks uncommon to the video game industry. This technology is still in development, some procedures are manual, and the documentation is far from complete. While there is high-level documentation on the game’s engine features, there was not enough low-level technical documentation, only pages with coding rules and some lists of tips. Productivity depended highly on the knowledge each developer could catch through oral transmission. As a result, knowledge is mainly passed orally within a restricted circle of each developer. We needed a process to train developers through efficient knowledge-sharing channels and raise their technical skills. Everyone turns to a few identified technical leaders, but they cannot answer all requests. Knowledge transfer is especially effective when one is close to these technical leaders. However, with teams spread across several sites, and as the technology is new, not all sites have technical leaders, resulting in a significant disparity in knowledge across the teams. In a nutshell, our main challenges were:
- How to scale knowledge sharing and best practices sharing? (beyond only oral transmission)
- How to push knowledge to developers when they need it? (instead of letting them search for it in our documentation tool)
- How to benefit from everyone’s knowledge? (and not only tech leaders)?
Why did you consider Promyze & how did the deployment take place?Within Ubisoft, there is in France a community of software architects that runs regular sessions. In one of them, architects from the game Mario Rabbids Sparks of Hope introduced Promyze and how they used it in their context. We identified that Promyze could help us solve the challenges we had. That’s why we decided to deploy Promyze on our project. We first tried it with a small team of experts and technical leaders. Even though the knowledge sharing process was already working fine, the team has been quickly motivated to use Promyze, especially with the automatic detection in Visual Studio. This has been a key element in our decision to deploy Promyze to all the teams. When we started to deploy Promyze for more engineers, we ran communication campaigns internally to promote the solution, explain our reasons to deploy it and the usage we expected.
What impact had Promyze on your team?Promyze has triggered plenty of communication and knowledge sharing, mainly on low-level engine and language topics. Best practices, which were oral until now, are now shared by the whole team in Packmind. The number of contributions is increasing months over months. It has been an opportunity to highlight and discuss lower-level practices, which was rarely the case before. Most of these practices are pushed back to developers in their IDE and are also regularly shared by email (one suggestion per day).
What did the code review extensions bring into this process?From my point of view, code review emphasizes more on how the code is implemented and written, rather than its expected business behavior. It’s thus the ideal moment to:
- Take into consideration the automatic suggestions provided by Packmind. They remind the mindset to have when doing the code review, in addition with the coding standards that have been defined ;
- Think about the code, its design, challenges, and suggest new best coding practices. The Promyze extension for code review allows to share practices beyond the scope of the review so that it will benefit not only the review’s participants. Besides, some of these practices have been labeled with the tag “Code review”.
What were the key factors of success?There is a need to have a group of regular contributors to bring new topics to discuss in the workshops to review practices. Also, we encouraged flexibility in the usage of the Promyze, so people were not forced to contribute for instance. From my perspective, Promyze can be seen as a tool with two main components:
- The knowledge base of best practices;
- The extensions for IDE and code review, allowing to push and get knowledge.