Synopsis: In this AI Leadership Insights video interview, Amanda Razani speaks with Peter McKee, head of developer relations at Sonar, about the need for clean code in the age of artificial intelligence.

Amanda Razani: Hello and welcome to our AI Leadership Insights video interview series. I’m Amanda Razani, and I’m excited to be here today with Peter McKee, who is the head of developer relations at Sonar. How are you doing?

Peter McKee: I’m doing well, thank you. Thanks for having me.

Amanda Razani: Can you share with our audience today, what does the company Sonar do?

Peter McKee: Yeah, so Sonar is very focused on software quality. We call it clean code. We have a definition on that. A code that is consistent, intentional, adaptable, and responsible. Those might not mean a bunch of things to our audience, but basically, how do you structure your code? How do you write good quality software? We focus on that. We have a static code analyzer that you can plug into your CICD processes and scan your code, looking for maintenance issues, reliability issues, security issues, those type of things. And then, we also have a slinter that sits in your IDE, kind of like Grammarly for engineers, so as they’re typing, we help them write better code. We’re very bullish on software quality and showing the value to business leaders and engineering leaders on, you should focus on not only functioning software, but also quality software.

Amanda Razani: Awesome. Thank you for sharing that. That brings us into our topic today, which is the importance of clean code. Before we get too deep into that, I just want to ask, how important is it to have clean code?

AWS

Peter McKee: Yeah, I think it’s paramount. I think the industry is very focused on functionality right now. Business leaders want high value features that deliver value to the business. They want those done without technical debt or as limited technical debt as possible, and they want them as fast as possible. They want them now. We do a good job around functionality testing, so unit testing. Unit testing really focuses on functionality, but we kind of miss the quality side of things, and I think quality is at the foundation of that, so clean code. You should have quality software before functioning software. I know I’ve written a bunch of software in the past that’s functioned well, but then I’ve looked at it myself two or three months later, and every engineer has a story and go, “Oh wow, who wrote that?” So, I think quality is the foundation of delivering those three pillars that business leaders want.

Amanda Razani: With that being said, I know we’re in a big AI age now and everyone’s focused on AI implementation. So how does that play a role as far as ensuring clean code now that AI is being used to generate code?

Peter McKee: Yeah, again, I think it’s even more essential now, if you could say more essential. I don’t know if that’s proper English, but you get my point. Generative AI is moving extremely fast. It’s getting better and better with each release, all the different players, all the different tools that are coming out. Very interesting new companies like Cognitive AI that just kind of released their Devin, kind of showed a demo of it, is bumping up against reasoning right now. But I think the bulk of the tools who are out there are producing code, and it’s not of the highest quality. There’s a lot of studies being done. I think GetClear is one of them comes to mind, where they’re showing that with the advent of AI, GenAI, that more and more code is being churned. So we’re producing more code, but we’re also fixing and changing that code a lot more.
GenAI does a really good job at producing code, but it’s not able to hold that full context of your application at once, so you’ll get solutions that might not fit exactly into your coding practices and standards, might not have the highest security standards, might not have the right versions that you’re currently using. And that’s okay for senior engineers, senior engineers, staff, principal engineers, we have the skill set and the whippings from the industry of check your coach, really be rigorous around your code, but more junior developers don’t know that, so they see the code, it works, so let’s use it. I think with the amount of code that’s being produced, the quality of that code that’s coming out is not the best, is subpar. Having a static analyzer like Sonar, SonarQube, SonarCloud, helping you out, running static checks on there, looking for clean code and helping you fix those issues is very, very important.

Amanda Razani: For business leaders who are struggling with this issue, what is your advice for them as far as what are the first steps when it comes to implementing some sort of technology or program that’s going to check the code for them?

Peter McKee: Yeah, I think what I’ve been talking about a lot is, they first have to understand that you kind of have that old three-legged stool of speed, cost, and quality, and speed is very, very important, but you can’t forget about the others. And qualities are very, very important. And again, while unit testing and integration testing, those things are very important, you can’t build up technical debt along the way because it’ll just hurt your business. And no business leader, we hate hearing, “Oh, yeah, yeah. Well, first we have to fix these issues that we’ve built into the code earlier.” And they say, “Why?” And the engineer says, “Because you wanted me to deliver faster.” I think that’s a mindset where you first have to start, is you’re missing a big piece of the SDLC, a huge piece there.
That mindset shift of, hey, let’s focus on quality and functionality will come after that. You’re already building functional software. You have those processes in place, but focus on quality first. That mind shift is very important. Second of all, involve your engineers. Involve your principal engineers and your staff engineers and have them start looking at our open source products. SonarQube is open source, SonarCloud, you can get a free tier on there, but run a POC. Bring it down, run it against your code, look at the issues. Now, usually what happens is you do that and you’re going to get thousands of issues. And as good engineers, we usually turn it back off and ignore it. No, just kidding. But take a step back and go, okay, well how do I attack this? It’s an issue.
I think the way you should think about that is not necessarily, a lot of times what happens is, a business leader will say, “Well, assign a more junior resource, a low cost resource to go through and fix all these things.” But again, you’re talking about quality and there are massive amounts of issues, let’s say 2,000 issues on a large code base. How do you prioritize? How do you fix those? There’s a methodology that we think about at Sonar called, Clean as You Code, and we’ve done some studies where about 20 to 25% of your code is being rewritten every year. About over five years, you end up close to 60, 50 to 60% of your code or more is cleaned, let’s say. And the rest of it might not be that maintainable, but it’s definitely reliable, or you would’ve had SEV 1, SEV 2s pop up.
Take an approach, a good solid engineering approach, to tackling those issues and run some proof of concepts and really rely on your engineering leaders to guide you through this. I think they’ll see the value in it very quickly. It helps reduce time for doing manual code reviews. It’ll catch issues that our brains just aren’t built to catch. There’s a lot of security issues and code issues that aren’t very obvious at first, and with cognitive biases and those type of things, our eyes skip over a lot of those things, so a machine is really good at that. And then, I would connect into SonarLint, which is our free plugin to IDE and pushing things left as fast as possible. You’re finding issues and fixing them as quick as possible. I think maybe those three things, kind of an approach to think about it.

Amanda Razani: It sounds like a critical component of the whole DevOps and Agile process, which I know you come from that background as well.

Peter McKee: Yeah, for sure. I would also involve your DevOps engineers. Get them involved earlier. They understand unit testing and quality gates, and they’re the gatekeepers of production, so to speak. If they understand what you’re doing, they see that value, then they’ll help advocate in the company for it.

Amanda Razani: Yeah, that brings another question I have. I know a lot of companies still suffer from silos, and it’s a big issue of concern as they try to break these silos. How important is that when it comes to the clean code?

Peter McKee: I think it has to be adopted, just like Agile and Scrum. You have to adopt it. It’s a mindset. You have to adopt it across the organization, and same here with co-quality. Everybody has to be bought into co-quality and see the importance of it. And I think in the long run, the business wins. The more quality software you have, the less churn you have of code, the less technical debt that you incur. And that means then, you can go faster and cheaper, and that’s what we want.

Amanda Razani: And then, I imagine they’ll see a better return on investment as well.

Peter McKee: A hundred percent. Plus, developer happiness and productivity. One of the biggest things for developers churning at companies, leaving companies, is they’re not doing the things they love. They’re not solving problems, they’re not writing code. They’re fixing past issues. They’re fixing codes that they or their team didn’t write. No documentation. The code is the documentation nowadays, which could be, without quality code, it becomes very hard to reason about these things. It helps with developer love. If they enjoy their work and their environment, they produce better code, they work better.

Amanda Razani: Most definitely. If there was one key takeaway you could leave with our audience today, what would that be?

Peter McKee: I might sound like a broken record, my apologies. But yeah, I think about software quality first, clean code first. And that is the foundation of a good software engineering team. And then from there, everything starts to fall into place, so I think that’s the key takeaway here.

Amanda Razani: All right. Well, thank you so much for coming on our show today and sharing your insights with us.

Peter McKee: Yeah, thanks for having me. I really appreciate it.

Amanda Razani: All right. Thank you.