Chapter 9: Code Quality and Security

Chapter 9: Code Quality and Security

Send Us Feedback

Listen on Itunes

Listen to Stitcher

Matt: Greetings, welcome to the latest installment of Building a Better Software Delivery Platform. I’m Matt DeLaere. Each week Compuware’s own Rick Slade draws from his years of experience to discuss one aspect of leveraging DevOps and Agile methodologies is to create a world-class software delivery system. Then each Friday, Rick answers your questions in a live Q&A session. So, without further ado, let’s say hello to Rick. Hi, Rick.

Rick: Hey, Matt. How are you today?

Matt: I’m good, thanks. How are you?

Rick: I’m doing well, man.

Matt: So, today’s topic is code quality and security, and we have a special guest who certainly understands such things. So, Rick, I’ll throw it over to you to introduce the topic and our special guest.

Rick: I appreciate that, and I am truly excited today. Many of you, or many of our customers are well aware of the company SonarSource and the incredible products that they are providing to our customers, to our industry. And what I really love about our SonarSource is its coverage of multiple languages. I was checking on a web page a while I go, I think they’re up to 27 different languages that they support now, and what they do is really incredible. They provide a level of automation that can have a significant impact on the total cycle time in any software delivery project. I won’t say anymore, I’ll let Nicolas talk about that.

But with us from Sonar today is Nicolas Bontoux. Nicolas is the Vice President of Marketing with SonarSource, and again, we are just incredibly excited to have him with us today. So, Nicolas, tell us a little bit about yourself, and SonarSource and its mission.

Nicolas: Yes, and so nice, I’m very excited to be here. Thanks for the invite, and for having me. So, indeed I am a “SonarSourceror,” as we say around. I’m joining right now from France by the border of Switzerland, where SonarSource is based in Geneva. And at SonarSource we’re basically… We’re all about code quality and security. What we want to build for the world is what you could call code analyzers, in fact. Products that will scan any type of code, not executed, it’s static code analysis, find bugs, vulnerabilities, any kind of quality security issue, so that’s kind of the immediate benefit. But to me the true mission behind that is to help really any team, any company making software to deliver higher quality and higher security software. And we have a number of values that we’ll probably cover throughout the discussion today, but really what is close to our heart is to help developers, development teams at first. What we truly believe is, end of the day, if you want to have a positive impact on the quality and the security of an application, you have to provide value to the people that just build this application, and those are the developers that write the code, maintain the code, improve the code over time, so this is how we approach things.

So, in fact, at SonarSource, to talk a little bit about the company, we’re mainly a company of a developers, of engineers building the technology, building the products. Myself, so, you introduced me as a Vice President of Marketing, but a couple of years ago, I was a software developer building software.

Rick: That’s awesome! I love it.

Nicolas: So, writing Python code, doing Python testing, and when I arrived at SonarSource, I was doing support, so support was really exciting because it helped me not just help people use the product, but really guide them in maxing out the value from DevOps tooling and from DevOps pipelines,and things like that. And so, that’s kind of the mission I’m taking and why I’m  happy to be here now today, which is to just talk in very simple terms to the communities about the value of code quality, code security, what it can really bring into the DevOps pipelines and the benefits for the end users. So, that’s about it for the intro.

Rick: That’s incredible stuff, Nicolas. I’ve had the opportunity to experience it and work with a little bit on the mainframe side, and I can tell you that I’ve spent the last 10 years talking to clients about how to modernize their software delivery environment and when I go into to an organization today, there’s not one where I don’t talk about the value of SonarSource and what it can provide. We’ve seen tremendous value with our customers in leveraging the tool because it can reduce the amount of time required to deliver quality code to a production set.

I am amazed at the number of rules, and I’ll let you talk a little bit about how it works a little bit later, but I was looking at the webpage a while ago, and I think there was like 182 different rules or policies that can be enforced within Sonar and what that means, and again, you do this for 26 other different languages, so you span multiple platforms, multiple technologies, I’m interested in the mainframe side of it, I know you support COBOL and PL/I. But again, looking through the rules for COBOL, 182 different rules, that’s a tremendous value in organizations that are looking to produce quality up front. I think that’s so important.

When people talk about “shift left,” they’re talking about building an environment that can identify problems early, where it takes less time and less money to correct those problems. And it begins with the quality of what the developer is producing and you guys provide products that significantly identify or have an impact on the identification of potential problems at the beginning of the process, and I think that’s so cool.

Nicolas: Yeah, and to me, here you talk about two things which are very, very complementary—I have to be careful not to say complimentary not complementary—which is you know, the technology itself. So, you talked about 180 rules, which to me speaks also for time, right? SonarSource has existed since 2008, so we haven’t started yesterday, this has been years since we’re building the technology, working with customers and teams and getting feedback, improving those rules and adding more. So, that’s something we’re, obviously from an engineering standpoint, super proud and excited about. And the other thing we paired it with is really our focus in making simple products for developers and in growing a community around quality and security, right?

So, as you said today, you mentioned, SonarQube, for example. I don’t think it’s specifically perceived as an enterprise tool or a product for companies. It’s truly a product that is used across all development teams and which speaks to the value it brings to individual developers, and then that value kind of rolls up at the organization level. And I think to the situation, to the success to describe as of today, it’s kind of what was our recipe over the years.

Rick: It’s incredible, we actually use it in our labs, the Lint product and the Qube products. I’m not going to talk about those because I want you to. In fact, right now would be a good time to tell us a little bit about your products and what they do.

Nicolas: Sure, well, you echoed one, you said Sonar, at some point. It’s always funny to hear people say Sonar because you know they know you for a long time, when they say Sonar. Sonar is the historical product, which in fact predates SonarSource to some extent, it’s really this open source community-based product for code quality, and this is where SonarSource chimed in to really bring it to the next level, add more languages, add a stronger UX for quality we’re now also on to security. So, SonarQube really is the flagship product. I think right now we’re somewhere north of 200,000 installs across all environments and all languages, so it has really become a standard for code quality, and now we’re looking also very closely at security.

The other one you mentioned is SonarLint, which is, you can see that SonarQube is really going to go into your pipeline, into your suite of tools, that really builds your traditional, you first build and then you test, and then you analyze, and then you deploy, and that makes your overall pipeline SonarLint for us was super-important because we wanted to go as close as possible to the actual developer environment, and devs, they write code in their IDE. And so, we said what about bringing the same technology directly when developers are coding into their IDE and developer environments on their laptop? So, really, really complementary, but speaks to the shift left, which you mentioned. And more recently, we also have SonarCloud as well, which is kind of obviously the cloud equivalent, but it’s not exactly SonarQube in the cloud, it’s more like a UX that is going to be even more fine-tuned to… If you have your whole pipeline in the cloud then there’s things that we can infer like authentication and finding the code, analyzing the code, etcetera.

So, those are our three products that we offer right now. On the COBOL and the mainframe, to be honest, I think the bulk of the adoption we’ve seen is around SonarQube within the on-premise pipeline and then SonarLint in the developer environment.

Rick: Yeah, I’ve had experience with Lint and with Qube, and I love both those products. Lint to me is like a spell checker for good coding practices, and so because the developer is working along writing or modifying code, you can use Lint to identify bad practices or policy violations instantaneously, so it’s like a spell checker for good coding practices. And I love that tool because again, that’s where it starts, and if we can identify issues early, that’s goodness. And the other thing I like about Lint and Qube, that rules database that supports both as I understand it, is that you can apply, you can add your own rules to it, which is amazing. So, if you’ve got standards within your shop that are important to you, and then you want some consistency in how that code is structured and how it’s written within all your applications, then you can enforce that automatically with Lint and Qube. That’s incredible value. The value from my mind is that if you’ve got consistency in your code, then when time comes to debug, to correct problems, logical problems, that consistency in that code base makes it much easier, much faster to identify problems and subsequently resolve them.

Nicolas: Yeah, and to me, that from our perspective, from the maker perspective, it speaks to… We’re always being pretty open and flexible, I think it would be a very bad approach to come up and claim that here is how cool COBOL code should be written, here is how that code should be written. We recognize that there is different environments, different standards, teams sometimes decide to apply a certain coding practice and not another, so this is why, obviously, we provide some built-in rules, but we also say, okay, some of those rules you can configure, sometimes you can import other rules. And it also speaks to the importance of just constantly taking feedback, right, so we have those community forums, totally open and it’s just super funny to see a developer from an open source project exchanging with a developer from a global organization. But they just talk about coding and they’re like, “Yeah, okay, we can maybe refine the feedback for this rule or that rule.” Especially, having been doing support at SonarSource, I don’t have a COBOL background myself, but I’ve been exchanging with COBOL customers and I was understanding their feedback, looking at it against the spec of the language, and they were like, yeah, sure, it seems like we got some things to improve and would be really working together them on kind of refining value and making sure that the end game here is that any feedback we provide to a developer should be accurate and actionable feedback, because when you start to generate noise for developers, you can be sure that that they may tolerate once or twice, but on the third time they’re going to be like, “No, this tool is not for me, because it sounds like an interesting value prop and feature set, but heck, every single… one issue out of five is a false positive,” and the signal-to-noise ratio becomes way too high or too low, I’m always confused, but basically, there’s too much noise and then they drop the product. So, this constant quest of hunting down the false positives, making sure we take the feedback into account, it’s something that is perpetual but that is super-important for adoption.

Rick: I love how you used the word “noise” because you’re exactly right. I haven’t heard it described as such, but that’s a perfect definition for what it is. Because if you’re getting information that’s really not relevant with regard to the work that you’re doing, then you’re right, developers are going to drop it, they’re going to turn it off and move to something else. I think you guys have done a wonderful job of making sure that the feedback that you’re providing your tool, definitely makes a difference and is important in the delivery of that code, so… We talked about COBOL. One of the questions I had was, why is it important, why was it important for SonarSource to provide support for COBOL, PL/I and the mainframe in general. I’m interested in your thoughts on that.

Nicolas: Yeah, so I think there’s… I can see two deep reasons. The first one is, and I wasn’t even at SonarSource back then, but when SonarSource started to build a COBOL analyzer, something which was pretty clear in mind is, we were going multi-language because our mission was not related to a specific language, it was really related to helping out developers. And once you say that, in some way you do not want to discriminate too much of like, “We’re only going to help developers of modern languages and not developers of that language.” Right? So, I think naturally, we were starting to engage with this organization and say we really want to build a product that is going to help you track code quality and security across your entire application portfolio, and make no mistake, a number of organizations would be like, “Oh right, well, we do have a number of mainframes or systems using COBOL, etcetera,” so it quickly appeared on our radar and we took up the challenge. And at the same time, I think it was a pretty exciting challenge because you realize now that’s not only are you bringing valuable tooling, but you’re becoming part of the few that are trying to bring modern tooling to technologies that have been there for a long time. And where people, some may say, “COBOL, it’s not modern, it’s not trendy anymore.” But the reality is that, no, it’s still there, there’s tons of systems running upon it, and we can help people make it a better experience, if we just provide state of the art, best-of-breed DevOps tooling to COBOL developers, then it becomes a smooth experience all of a sudden. So, it kind of hit many, many points in two values that are important for us, and I think it turned out to be pretty successful pretty rapidly because of the fact that we took up this challenge. Does that make sense?

Rick: Yeah, it does, it does. And I’m so glad that you guys took this on because I love your perspective on it, Nicolas, in that regardless of platform or regardless of target, software development is software development. And there are differences in language, linear languages differ from object-oriented languages, but again, software development is software development, and if organizations are asking our developers to make changes to these systems and where there is integration or there are mainframe components, then the mainframe developers should have access to the same wonderful technologies that are available to any other developer, and that’s one of the reasons I love SonarSource and what you guys are doing so much. You bring those same capabilities to the COBOL coder.

And I think what you’re doing and what Compuware is all about, is you’re building or providing functionality, features, components of a software delivery system that can span multiple platforms so that the software developer can work from an environment that looks essentially the same, you’re able to navigate the tooling essentially the same, regardless of your target platform. And I think that’s just going to have a tremendous impact on productivity and on the cost of delivering software because you’re going to be able to move people around, and Sonar and what you’re doing with code assessments, ensuring code quality and security is a critical, critical part of that.

Nicolas: Yeah, and I’m going to put on my engineer hat for a second, which I put less and less, but it’s close to my heart. We engineers, we just want to solve problems, right? And whatever the challenge, whatever the problem, we’re just up for it, provided we’re being given good, reasonable tools to tackle problems. If you use tools from decades ago, it’s going to be feeling like, “Come on, you know, we’re in the 21st century here, we have better tools to do this.” But then, if you give the right tools, if you give the right environment, well, whatever the challenge, whatever the underlying problem, we’re just going to go chase it down and fix it, and suddenly you start to abstract what technologies are used to build things or whatever, you just make sure that you have the most modern tools to solve problems and write quality software.

Rick: I totally agree, Nicolas, totally agree. With your work with providing the support for the COBOL programmer, have you seen any issues with regards to traditional developers, people like myself, being able to transition or being able to leverage tools like Lint and Qube from SonarSource?

Nicolas: So, we’ve seen some patterns, for sure. I’m not sure if I would be calling them issues, but I can see two patterns which the move from the waterfall approach to the Agile approach or from also the tooling side. It’s more than a checklist of, “We going to change tools and we’re going to do stand-ups instead of those meetings.” There’s the overall, I would say mindset, like the human aspect, but also from a pipeline perspective, you have to put your whole pipeline upside down potentially. And for example, if you only bring SonarQube, it’s not going to do much, right? It’s really the overall approach you have. So, I think this is where typically, this is where us working with Compuware makes sense, right? It’s like we’re not going to pretend that by just bringing SonarQube, magic happens overnight. It also comes from having a holistic approach at the mainframe and the overall pipeline, and work with the other partners. On the transition side, something we’ve observed, and this is… We actually had to build something in the product there… A typical reaction is like, “Okay, sounds great, let’s go for it.” People analyze their code and first things first, the product reports like, I don’t know, 200 bugs and 150 vulnerabilities and a massive technical debt, and you feel like totally overwhelmed by this tsunami of issues here and issues there, and you tend to be like, “Okay, where do I start from?” We had to put the technology aside for a second and we had to help with the methodology, and help with the product UX. So, the way we call it, I will give the name first, in fact, we call it “Clean as You Code.” In our products, we actually put it as part of the UX itself, and it’s based on a pretty simple premise, is putting in place a contract with the developer, development teams where we tell them, “Look, it’s totally okay to have legacy issues, legacy problems on legacy code, don’t feel any pressure to go start a sprint just to fix all bugs because that might in fact create more problems.” Instead the simple contract is just from any new code that you write or that you touch from now on, this is what you should be having a super-close look at code quality and security. This is what the product is going to focus on through the UI, through the UX. And it’s a very fair thing to do, right, because developers are like, “Okay, fair enough, I’m just going to write my code and take into account any feedback I have from the tool,” and then what happens over time as this goes, is that developers by nature, they don’t always write new lines of code, they often time they re-factor, the touch old lines, etcetera. And so, what naturally happens is you end up covering the bulk of the code base over time.

Rick: Nicolas, I couldn’t agree more with what you’re saying with regard to your methodology. When I talk to clients about modernizing their software delivery environment, one of the things that inevitably comes up is technical debt within the applications, and my advice has always been that it’s something that has to be attacked incrementally. As you are attacking new projects, new activity, you take on some of that incrementally. And I think that’s the best way to address it.

I know we’re running short on time. I had one last question I wanted to run by you, and I think it’s so important because I was telling Matt earlier, I’ve been doing this for a long, long time now, and at least in the last three years, everywhere I go—and I spend a lot of time with a lot of clients—everybody’s heard SonarSource, and so you’ve been wildly successful. At least that’s my perspective, based on the people I’m talking to. Now, probably we’re meeting with a lot of the same people who are interested in modernizing software delivery, but talk to me a little bit about what the primary drivers or the primary reasons that SonarSource, in your mind, is being so successful in the marketplace? Why is that?

Nicolas: A big mystery, right? We all wish we knew exactly the secret ingredient that makes it so successful. I think it’s always hard to say which pprecise ingredients, which precise proportion. I see a mix of things. So today, we’ve covered a few things, right, we’ve talked about the technology, we’ve talked about reducing the noise for developers, if I were to abstract it even more, something we say often SonarSource is we’re a product first company, right? The first thing we care most about is making a great product, and it’s… Once you have that in mind that you start to look so closely at not generating noise, having a powerful UX that delivers are truly going to embrace and having a good methodology.

We have a simple way even to kind of check against that, which is we say, “We eat our own dog food.” We use our own product, maybe not for COBOL code all day long, but for many different languages, and so we’re the first to experience what is our product actually offering. So, I think this focus speaks to a lot of things, and then it’s those ingredients that we talked about. So, going multi-language to make sure that as much development teams can leverage product and the technology, opening a community, really open for any to open source so that people can exchange, but they can also contribute back, they can share feedback, they can iterate upon each other’s feedback. So, to me, those are some of the important values that, end of the day, it’s like we want to make sure that whenever we give feedback about code, it’s to the right person, it’s given at the right time within a DevOps pipeline, right? You want to make sure that you’re at the right place, and that’s how you get people happy and when people are happy, then magic things happen their own.

Rick: Well, you guys have done some wonderful work, you’re making a difference in the time required to deliver software, and I think that’s always going to be attractive to the market. You guys are a critical and have been a wonderful partner with Compuware and we appreciate what you’re doing for your clients, what you’re doing for our clients, and how you’re working with other vendors to, again, as you described, create an entire ecosystem that is built around improving performance in software delivery. So, we appreciate that. I want to thank you again for coming on this podcast today. Man, you are just a wealth of information. At some point in time, we’ll look forward to having you again, but again, thank you.

Nicolas: Thanks to you guys. I will remember this one always, this was the first podcast I contributed. So, I’ll be able to tell that to family and kids one day.

Matt: You did great.

Nicolas: Happy to be here again. Thanks for the invite.

Rick: Thank you, Nicolas, we appreciate it. Matt, you want to wrap us up?

Matt: Sure, and thanks again, Nicolas. Thank you, Rick, and as always, thank you to our listeners. Don’t forget to bring your questions about code quality and security or any other aspect of the software delivery system to our live Q&A session, Office Hour with Rick Slade this Friday at 11 AM Eastern Daylight Time. Visit to set a calendar reminder, to listen to the entire series and to watch recordings of past Office Hours with Rick Slade. You can also submit questions on Twitter using the hashtag #goodcoding. So, Rick, until Friday and next week, I’ll leave the last word to you.

Rick: Thank you, Matt. Thank you, Nicolas.

Guys, thank you for joining us today. Great information. SonarSource is an intricate part to a modern software delivery environment because it gives you the ability to find potential issues early, early in the process where it takes less time, less money to correct, so… Good information today, I appreciate it. If you’ve got other questions, as Matt’s already indicated, please join us on the live Q&A on Friday, and again, as Matt indicated, more information can be found at Have a great week. everybody, a great weekend. And good coding.