Every developer knows the feeling. You open a ticket that looks simple. A small change. Maybe one endpoint, one validation rule, one extra field. Then you open the codebase.
The logic is spread across three layers. The naming is inconsistent. Tests are missing or outdated. A dependency throws warnings. One change breaks something unrelated. Suddenly, the “small ticket” is no longer small.
This is where code quality stops being an abstract engineering ideal and becomes something very concrete:
speed.
During the PSG technauts TechNight on June 15, 2026, Dick Dijk gave a talk about SonarQube and code quality. But the most interesting part was not the tool itself. It was the problem behind it: how do you keep a codebase workable when teams, features, frameworks and deadlines keep changing?
Developers Do Not Need More Noise
Most developers are not against quality tooling. They are against tools that only add noise. A useful tool should not just say: “This is wrong.”
It should help answer better questions:
- Is this actually risky?
- Why does this matter?
- Should we fix it now or later?
- Is this a new problem or old technical debt?
- Are we making the codebase better or worse with this change?
That distinction matters. Because developers do not need another dashboard to ignore. They need feedback that helps them make better decisions without slowing them down.
Technical Debt Is Not Always the Result of Bad Work
Technical debt is often framed as the result of shortcuts, messy code or rushed decisions. Sometimes that is true. But often, technical debt simply happens because software ages.
- A library that was fine two years ago now has vulnerabilities.
- A framework version reaches end of life.
- A pattern that once made sense no longer fits the current architecture.
- A quick fix becomes permanent because the product moved on.
That means technical debt is not just a sign that someone did something wrong. It is a natural part of software development.
The real question is whether your team can see it, discuss it and control it.
Code Reviews Cannot Catch Everything
Code reviews are still one of the most valuable practices in software development. But they should not carry the full burden of quality.
A reviewer should be thinking about design, readability, edge cases and business logic. Not manually checking every possible security rule, duplication threshold or maintainability pattern.
When reviews become overloaded with things that could have been detected earlier, they become slower and less useful.
That is where static analysis can help. Not by replacing review, but by removing some of the repetitive checks from it.
So Where Does SonarQube Fit In?
SonarQube is one way to make code quality visible. It scans code without executing it and reports issues such as bugs, security vulnerabilities, code smells, duplication and missing test coverage. These issues are ranked by severity, from informational findings to blocker-level problems. The useful part is not that a tool finds problems.
The useful part is that it creates a shared language. Instead of having vague discussions like “this feels risky” or “we should probably clean this up”, teams can look at concrete findings and decide what matters.
That does not mean every finding is automatically important.
- Some issues should be fixed.
- Some should be marked as false positives.
- Some rules may not fit your project.
- And some old issues may simply not be worth touching right now.
The value is in making those choices explicit.
The Most Practical Idea: Do Not Try to Fix Everything
The moment you run static analysis on an older project, you may discover hundreds or thousands of issues.That can feel discouraging.
But trying to fix everything at once is usually the wrong move. It creates a huge cleanup project, slows down feature work and often loses momentum before it delivers value.
A more realistic approach is:
do not make the codebase worse.
This is the idea behind “Clean as You Code”.
Focus on new and changed code. Keep the part you are touching clean. Prevent new critical issues from entering the codebase. Improve things gradually as part of normal development.
For developers, this is important because it respects reality.
- You do not have to stop building.
- You do not have to rewrite the entire system.
- You do not have to carry every historical decision on your shoulders.
You just make sure the code you touch leaves the project in a slightly better state.
Fast Feedback Beats Late Feedback
The earlier feedback appears, the more useful it becomes.
- Finding an issue while writing code is better than finding it after pushing.
- Finding it before review is better than finding it during review.
- Finding it before the release pipeline is better than finding it minutes before deployment.
That is why IDE integrations such as SonarQube IDE can be valuable. They bring feedback closer to the developer, while the context is still fresh.
But the principle is bigger than any specific plugin:
quality feedback should happen where it costs the least to act on it.
Quality Gates Are Not About Blocking Developers
Quality Gates can sound like bureaucracy. A red gate. A failed build. A blocked release.
But used well, they are not there to punish developers. They are there to protect the team from unclear expectations.
A good Quality Gate answers the question:
“What is the minimum quality level we agree on for new code?”
That might include no new critical vulnerabilities, acceptable duplication, or a minimum level of test coverage.
The key is that the gate should be meaningful, realistic and understood by the team. If it is too strict, people will work around it. If it is too weak, it becomes decoration.
The goal is not perfection. The goal is consistency.
AI Will Make This Even More Interesting
One of the more forward-looking parts of Dick Dijk’s talk was the link between code quality tooling and AI.
If AI coding assistants can access quality data, they can do more than generate code. They can reason about the current state of a project.
That opens up questions like:
- Which files have the most serious issues?
- What changed in quality after this pull request?
- Can these blocker issues be fixed safely?
- Where would a refactor have the biggest impact?
Tools such as SonarQube MCP and remediation agents point in that direction. But even here, the interesting part is not automation for its own sake.
The interesting part is whether AI can help developers spend less time on repetitive cleanup and more time on technical decisions that actually require judgement.
The Developer Takeaway
The real lesson from the talk was not: “You should use SonarQube.”
It was this:
A codebase does not become difficult overnight. It slows down gradually, through small decisions, outdated dependencies, missing tests, unclear standards and postponed cleanup.
The same is true in reverse. You improve a codebase gradually, by making quality visible, catching issues earlier and refusing to add new debt without noticing.
For developers, that means less friction, faster feedback and fewer surprises. Not perfect code. Just a codebase that keeps working with you instead of against you.
