Qodana User Spotlight: Meet Fullstack Software Engineer Drew Penrod

Drew Penrod is an experienced fullstack engineer at a company that makes phones designed for kids using Samsung Galaxy hardware running custom software. He and his team develop and maintain an Android-based platform that gives parents control over apps, contacts, screen time, messaging, and browsing through a web-based interface.

As the company and its engineering organization have grown, maintaining consistent code quality, security visibility, and policy enforcement – across multiple repositories and language ecosystems – has become increasingly important.

In this interview, we spoke with Drew about introducing Qodana into the team’s workflow, the challenges they were trying to solve, and what they’ve learned during rollout.

Can you tell us about your role and your team?

I’m a career full-stack software engineer, currently working as a DevSecOps engineer. My day-to-day sits between the engineering teams and the systems they ship through: CI/CD, pipelines, developer tooling, and the security and quality controls that run alongside them.

Alongside that, I’ve built several internal services that support our DevOps work, done a lot of PR and code review, mentored other engineers, and dug into time and space complexity and other performance issues across the codebase. I drove the Qodana adoption directly, from evaluation through to rollout.

What were your biggest challenges around code quality before Qodana?

We already had written standards for code style, pull request reviews, and QA. Style guides existed for TypeScript, Kotlin, and React. Every PR required two reviewers. What was missing was consistent enforcement of any of it.

ESLint ran in some places, sometimes locally, sometimes during a build, but it was not a formal CI step. Prettier and tests were reliable; but static analysis was not. Across several language ecosystems and a growing repo count, that meant standards were applied unevenly, depending on which repo a developer was working in and who reviewed their PR. There was no single place to see whether quality was getting better or worse over time.

How did you manage code reviews and quality checks previously?

Reviews were manual, with two reviewers per PR, against the written style guides. Automated checks in the pipeline were limited to formatting and tests. Linters ran inconsistently across repos, and there was no shared static analysis layer enforcing the same rules everywhere. Anything that needed deeper inspection (security issues, license problems, dependency risks) was caught case by case, rather than as a pipeline step.

Were there any specific compliance or security requirements you needed to meet?

Yes. The product we sell goes on kids’ devices, so security and dependency posture matter to us. We’re working toward alignment with CIS Controls v8 and the NIST Cybersecurity Framework (CSF) 2.0. Those frameworks shape how we think about the development pipeline.

Several of the controls land directly on the kind of work Qodana supports. CIS v8 Control 7 covers continuous vulnerability management, and Control 16 covers application software security, which calls out static analysis and secure coding practices specifically.

CSF 2.0’s Protect and Identify functions cover similar ground: knowing what’s in your software, knowing where the risk is, and keeping controls between vulnerable code and production. For us, these frameworks lead to the same practical requirement: automated checks that run on every change, with results we can audit later.

Drew’s take on Qodana 

What made you start looking for a solution like Qodana?

A few things lined up at once. The pipeline itself was being modernized, and we wanted to fold static analysis, SCA, and license checks into it. Our Dependency Update Policy needed enforcement tooling, and the inconsistency across repositories was getting harder to ignore as the codebase grew. We needed a single tool that could provide coverage across our languages and run in both CI and the IDE.

What other tools did you consider?

We looked at SonarQube, ESLint-only setups, and standalone software composition analysis tools. Each covered part of the problem. None covered the full surface area without significant operational overhead or a patchwork of tools to integrate.

What stood out about Qodana?

Qodana fit the requirements better than the alternatives. It covers static analysis, dependency scanning, style, coverage, and license auditing in one platform, across the languages we use.

It runs the same inspections in JetBrains IDEs that the pipeline runs in CI, so developers see findings before they push rather than after a pipeline fails. It integrates with our existing CI platform and supports global configuration so rules stay consistent as repos are onboarded.

Getting set up

How did you introduce Qodana into your workflow?

Adoption has been incremental. Qodana was wired into pull request and main-branch pipelines through a shared pipeline mechanism, so individual repos can be onboarded without each team rebuilding CI from scratch. Each onboarded repo gets a baseline so existing findings are scoped separately from new ones.

Right now we are moving toward soft gates. A few repositories are running pilots of both soft and hard gates, but soft gates have not yet been rolled out to all repos.

How long did it take to see value?

We started getting value as soon as findings showed up in PRs and in the IDE, well before any gates were turned on. Visibility into dependency vulnerabilities and license issues was the first noticeable win, because those previously surfaced inconsistently across repos. Putting all that information in one place changed how we triage updates.

Were there any challenges during adoption?

Some of the pacing has been shaped by limitations of our underlying CI platform, which has affected how quickly we can promote soft gates to hard ones across the organization. Onboarding a polyglot codebase also takes time per ecosystem, since each one needs its own configuration and baseline. None of this has been blocking, but it is the reason we are still rolling out rather than fully enforced.

What impact has Qodana had on your code quality?

Rollout is still in progress, so most of the impact so far has been in visibility rather than in pipeline enforcement. Qodana has surfaced about 99,000 issues across the codebase.

That number is a starting baseline, not a count of issues fixed, and it covers code quality, style, and security findings together. Having those numbers in one place is itself useful: before Qodana, there was no consistent way to compare quality across repos or languages.

Have you seen changes in the complexity and functionality of your codebase?

Performance and complexity work is something I spend real time on, and Qodana has been useful as another lens on it.

The inspections surface things like inefficient loops, redundant work, and patterns that hint at deeper time or space complexity issues, which gives me a head start when I’m reviewing PRs or going back to look at hotspots in older code. It is not a replacement for understanding an algorithm, but it does flag enough that we end up having those conversations earlier than we would have otherwise.

It’s still too early to claim broad measurable changes in complexity across the whole codebase, since rollout is ongoing. The pilot repos are where the cleanest signal will eventually show up.

Has it helped with compliance or security processes?

Yes. Dependency vulnerabilities and license issues are now visible in PRs and inside the IDE, where they previously surfaced inconsistently.

That is also what gives our Dependency Update Policy something to attach to, since CVSS thresholds, license rules, and audit checks can run in the same pipeline developers already use. Once we finish the soft-gate rollout and begin promoting hard gates, those policy rules become enforceable rather than aspirational.

Ready to improve code quality across your repositories?

Qodana helps development teams bring static analysis, dependency scanning, license auditing, and quality enforcement into a single workflow, directly in the IDE and in CI/CD pipelines.

Try Qodana and see how your team can improve consistency, visibility, and code quality across every repository.

Try Qodana

Special thanks to Drew Penrod for his participation in this interview. We wish you and your team continued success!