Convincing Leadership to Perform Code Analysis

Problem

"When I started working at Mobiquity, they had Agile Scrum and were doing continuous integration, but the one thing they lacked was code quality measures. About six months after starting, I installed and started using a static code analysis software called SonarQube. While it wasn't a big challenge to use this for my projects, it was difficult to show the value and to get buy-in from people above me in the organization, as they had no way of knowing how bad the code really was."

Actions taken

"I decided to run the analysis software against projects we had been working on. By doing this, I was able to demonstrate the difference between the project I had done with SonarQube and their quality reports and the projects that never had a quality report run on them and their quality reports. The difference was dramatic. While my project had three days of technical debt, the project they had been working on for over four years had 99 days of technical debt. This was huge, as it would take $50-100,000 to tackle this technical debt. Our VP of Engineering was both disappointed and excited - while disappointed that things had gotten that bad, he was excited about the opportunity to make changes. By showing value, I was then able to get buy-in to get the supported version, support, and the plug-ins we needed for the different languages we use. Two years ago, we mandated code analysis company-wide. Since mandating it, all of our projects have gone to production with less than five days of technical debt, because when Engineers see that their code isn't great, they fix it."

Lessons learned

"Never go to your manager without data - you need to be able to prove your argument with tangible facts. I was actually surprised by how quickly management bought-in to my plan. I thought I'd still need to fight for a change, but because I had the data to back-up my points they got on board really quickly."