Console

What is SonarSource? Why did you build it?

SonarSource was created 14 years ago by three partners - myself and two friends. We had three perspectives on the same problem: clean code. I was leading a small development team with junior developers. It was really difficult because they had a hard time understanding that if they were not careful with the "quality" of their code, it would backfire. Their mindset was, if the feature works, then what else do you want? I was having a hard time reviewing the code, so we started to enforce some basic syntax rules.

I knew it was not enough. One of my partners was trying to implement CMMI Level 3 and was trying to put a code review practice in place. He wanted to have it automated and couldn't find a product for that and our third partner was really concerned about developing software that wasn’t good enough. So this is how we started with an open source product and created the company.

Over the years, we have evolved our efforts a bit as the need arose. There have been periods where we focused more on the product, more on the community, more on adoption, more on packaging, and growth of the business. But throughout this time, we have always been pursuing the same goal at SonarSource, which is helping organizations to do a better job with their code.

We have several products, which a developer will use as part of their workflow starting with their IDE. When they code, they will see existing problems and as they are typing code, they will see the new problems that they're potentially introducing. Our solution, called Sonar, gives them an immediate opportunity to not introduce a problem, because as long as it is on the local machine, we can consider that the ‘problem’ doesn't exist. It's only when you start to push it back into the main or feature branch that the problem really exists. We have this safety net for developers - as you code, you see problems and get an opportunity to fix them.

Nowadays when you commit your code, you are not going to push into a master branch - you are going to create a change request, pull request, merge request, whatever name you give it, and somebody else is going to review it. We’re present at this stage too. We decorate or comment on the pull request. We show the developer and reviewer what issues we found - to enable an educated decision on whether to merge. Sometimes we notify them about blockers and why they cannot merge.

To me, these are the main two parts of what we can do for the development team, but there is also the ability to explore the code, explore all existing issues, etc. I think it generally doesn't make sense to do this all the time, but for architecture developers, and audit teams, it can be crucial.

What does a "day in the life" look like for you?

Lots of meetings, which is hell! I’m only joking! It is my first experience as an entrepreneur, CEO. I've been here for 14 years now - I've surely grown a lot, I've learned a lot, I've really changed the way I'm working. But I'm still the founder of the company. We have a fairly low turnover, so I've got a lot of strong relationships with several folks that joined early on. We have almost 400 people now. I still interview each candidate as the last step.

People are very engaged in the company. I think we have a very engaging culture where people can have an impact. They know the impact that they have, so they're really serious about it. So for me, when people are knocking on the door, I would let them in and discuss, et cetera. Basically, I'm spending a lot of time in meetings. I also travel a lot, I've got three kids, a house, a dog, and I'm doing Ultra-trail, so I optimize my time.

What is the team structure around SonarSource?

We have five legal entities in five different locations but the company is one company - we are just a distributed organization. We have one head of finance, marketing, and sales. We are distributed across five locations because it is both strategic and opportunistic. It is strategic because we just went to Asia, so we opened an office in Singapore, and we are going to grow a sales office there. And also opportunistic, because if we struggle to recruit engineers in Geneva, it's a small city with many banks, but not so many engineers, we can hire more engineers in Bochum, Germany, where there is a 50,000 student university.

For a very long time, we have not introduced any glue functions - all the functions that you add because you start to see friction where two teams cannot work together. You add a product manager who is going to help sequence what needs to happen, et cetera. We prefer to work back at the source of the issue, what I mean by this is we added a lot of soft skills in our teams to have people who are not only driven by technical problems, but who also understand collaboration. We then started to define company objectives, which are shared objectives to be a forcing function of having teams collaborate rather than working in silos. Every time the word project manager popped up in a room, we went back to the root cause and we tried to address it, so for a very long time, we have been fairly flat as an organization.

We assign responsibilities to teams rather than relying on individuals. We say that the team is responsible for X, Y, Z, and we are going to staff it to make sure it can fulfill these objectives. Today we have an engineering team which is extremely flat with a council, which is made of several people who are going to take care of the growth of individuals. They take care of making sure that the way the team is organized is optimal, that objectives are shared, understood, and that we are working on them.

One of our teams has 50 members and they have a weekly meeting of one hour. That’s it. It's still a well oiled machine, which is extremely effective. We have people who are helping individuals to be autonomous. There is a management team now, which meets bi-monthly to make sure everything is going as planned.

How did you first get into software development?

I got into software development when I was at school in France - I was actually in something called Applied Mathematics. At some stage, you need to do some theory, you need to do some applied mathematics, which is all the algorithms to approximate problems. And then you need to implement them to see the results. I chose the software side. To be honest, I thought it was the easiest, I was a little bit lazy at the time. I also did an internship at JP Morgan which I continued throughout my last year in college.

I also did a lot of coding. I realized later when I worked with one of my partners that I was not a very good developer. I always thought that if I put more effort, I would become a good developer. But when I sat next to my partner, I realized we were not playing in the same league, and I would never be able to go to his league! I was always more interested in engineering, which is approximately what we do now. We solve problems like “how do we build it”, “how do we make sure it can scale?”, “is the development repeatable and predictable” and that's really one of my strengths.

I mainly learned Java. I tried a little bit of C++, but I never liked it. I did some HTML and JavaScript but I think the main language I worked with was Java. This is the one I was most familiar with, but I kind of stopped coding a long time ago. I think the last time I coded something, I sent the code to somebody to integrate because we hadn’t transitioned to git yet. I actually wrote some code last weekend with my daughter because she asked for my help with her C++ code for her university assignment. But I think we have built such a team at SonarSource that I don't feel like I can add any value by coding.

What is the most interesting development challenge you've faced working on SonarSource?

I think the way we approached the whole journey at SonarSource was really to build something, so we very rarely make huge changes. We have been incrementally developing the product - if you look at SonarQube, we have pretty much delivered a new version every two months for the last 14 years. Sometimes we deviate from that schedule because we’re always looking to optimize - there’s a cost to every release. Our goal has been to minimize that cost and maximize the value delivered. We have made some big changes, but we always try to make them incrementally by splitting it into smaller changes and pushing these changes.

I remember a few changes that we made that were a game changer; we had this Sonar plugin for Eclipse and one day I was going to make a presentation at the conference and it took 27 seconds for my project to be analyzed. We then decided to change the architecture so that it would work much faster! It took us six months to make that change because of the large amount of work needed. From a functional point of view it was a game changer.

Another one was when we forked SonarCloud from SonarQube to ensure we didn’t run up against product and use-case limitations down the road. It wasn’t necessarily a big technical challenge really, more of a big technical decision to maintain an open, greenfield scenario for both products.

What is the most interesting tech tool you are playing around with at the moment?

For a long time, I have been playing with a lot with frameworks and tools like JIRA, but I've also been observing things like Azure DevOps. Nowadays the tools, the frameworks I'm looking at are much more around my own organization. Sure, I look at technology to keep things under control for myself, but mainly it’s around the business side.. We have around 350,000 companies and 6 million developers that use our product. It would be really cool to better understand the life of the people who are in our ecosystem and how they like to work. For instance, we have commercial customers very engaged with our Community Forum.

I'm more like a product guy and I really would like to better understand how we can make sure that people are maximizing the value they get out of SonarSource. There are so many developers who use SonarQube and don't use SonarLint - which is a free tool. But today, my challenge is to better understand how to create awareness here and that's something I would like us to build. Some people call it product marketing or whatever, but to make sure people really understand what we do and the values they can get out of it.

Describe your computer hardware setup

In my office, I have an iMac with a 27 inch 5K screen which is generally okay because I do a lot of meetings in the office. When I want to do some proper work, I use two screens as my setup. For traveling, I now use an iPad Pro with a separated keyboard, which is really cool to stay focused. I'm using an Android phone; I tried several times to switch to iPhone, but I hated it!

Describe your computer software setup

OS: macOS.

Browser: Chrome and Safari.

Email: Google Mail.

Chat: I use Zoom chat, but most of our teams are on Slack.

IDE: IntelliJ.

Source control: Git and GitHub.

Describe your desk setup

One fancy thing in my office that I have is a neat board, which is a Zoom appliance. It is a TV with a camera, microphone and speaker, all integrated into one unit. It also has a touchscreen and a white board included.

When coding

Daytime or nighttime? Day.

Tea or coffee? Coffee.

Silence or music? I like both.

What non-tech activities do you like to do?

I run Ultra-trails in the mountains. I enjoy that a lot.

Find out more

SonarSource helps you build high quality code. It was featured as an "interesting tool" in the Console newsletter on 10 Nov 2022. This interview was conducted on 29 Sep 2022.