Eating the dog food
The SonarQube platform includes an increasing powerful lineup of tools to manage technical debt. So why don’t you ever see SonarSourcers using Nemo, the official public instance, to manage the debt in the SonarQube code? Because there’s another, bleeding-edge instance where we don’t just manage our own technical debt, we also test our code changes, as soon as possible after they’re made.
Dory (do geeks love a naming convention, or what?), is where we check our code each morning, and mid-morning, and so on, and deal with new issues. In doing so, each one of us gives the UI – and any recent changes to it – a thorough workout. That’s because Dory doesn’t run the newest released version, but the newest milestone build. That means that each algorithm change and UI tweak is closely scrutinized before it gets to you.
The result is that we often iterate many times on any change to get it right. For instance, SonarQube 5.0 introduced a new Issues page with a powerful search mechanism and keyboard shortcuts for issue management. Please don’t think that it sprang fully formed from the head of our UI designer, Stas Vilchik. It’s the result of several months of design, iteration, and Continuous Delivery. First came the bare list of issues, then keyboard shortcuts and inter-issue navigation, then the wrangling over the details. Because we were each using the page on a daily basis, every new change got plenty of attention and lots of feedback. Once we all agreed that the page was both fully functional and highly usable, we moved on.
The same thing happens with new rules. Recently we implemented a new rule in the Java plugin based on FindBugs,
"Serializable" classes should have a version id. The changes were made, tested, and approved. Overnight the latest snapshot of the plugin was deployed to Dory, and the next morning the issues page was lit up like a Christmas tree.
We had expected a few new issues, but nothing like the 300+ we got, and we (the Java plugin team and I) weren’t the only ones to notice. We got “feedback” from several folks on the team. So then the investigation began: which issues shouldn’t be there? Well, technically they all belonged: every class that was flagged either implemented
Serializable or had a (grand)parent that did. (Subclasses of
Serializable classes are
Serializable too, so for instance every
Serializable.) Okay, so why didn’t the FindBugs equivalent flag all those classes? Ah, because it has some exclusions.
Next came the debate: should we have exclusions too, and if so which ones? In the end, we slightly expanded the FindBugs exclusion list and re-ran the analyses. A few issues remained, and they were all legit. Perfect. Time to move on.
When I first came to SonarSource and I was told that the internal SonarQube instance was named Dory, I thought I got it: Nemo and Dory. Haha. Cute. But the more I work on Dory, the more the reality sinks it. We rely on Dory on a daily basis; she’s our guide on the journey. But since our path isn’t necessarily a straight line, it’s a blessing for all of us that she can forget the bad decisions and only retain the good.