Increase Code Quality with LinearB
Over a third of developers spend 25% of their time fixing bugs - time that could be spent building features or optimizing code. Poor code quality translates to wasted time, lower planning accuracy, and ultimately less value delivery.
This needs to change.
This needs to change.
The Anatomy of Code
Quality Improvement
High code quality should be a priority for development shops. Why? Higher code quality means:
Better performing apps
Shorter cycle time
Better planning accuracy
More value delivery
Code quality improvement begins and ends with PRs and the review process.
Here’s the step-by-step path to continuously improving code quality with LinearB.
Here’s the step-by-step path to continuously improving code quality with LinearB.

1. Benchmark your metrics
Use this as an opportunity to identify areas where you can improve. If they don’t exist, congratulations! Celebrate the win!
But odds are your team can improve code quality. A good way to find out for sure is to look at a key lagging indicators and crucial DevOps Research & Assessment (DORA) metrics such as:
But odds are your team can improve code quality. A good way to find out for sure is to look at a key lagging indicators and crucial DevOps Research & Assessment (DORA) metrics such as:
Change Failure Rate (CFR)
Mean Time to Restore (MTTR)
Code churn
These are lagging indicators because they’re calculated after code is deployed to production. LinearB’s historical analysis of your Git and release data shines a light on these problem areas and helps you identify ways to improve code quality.
As an example, a high CFR and consistently large PRs (more on this in the next section) tells you that code quality is a problem.
For context, the best teams have a CFR <15% and a MTTR of 5 hours of less...What’re yours?
As an example, a high CFR and consistently large PRs (more on this in the next section) tells you that code quality is a problem.
For context, the best teams have a CFR <15% and a MTTR of 5 hours of less...What’re yours?
2. Get the whole picture
Lagging indicators are important. But they only tell half the story.
You need to combine them with leading indicators (e.g. PR size and review depth) to establish baselines and ensure that everyone understands where they are and the journey ahead. After all, improvement is a team sport.
The cornerstone of code quality is the size of PRs. Why? Smaller PRs:
The cornerstone of code quality is the size of PRs. Why? Smaller PRs:
Simplify reviews
Increase review depth and engagement
Minimize cognitive load for reviewers and requesters alike
Decrease the chances of PRs getting merged without a review
Reduce the chances of introducing new bugs
Bottom line: Smaller PRs, deeper reviews, fewer PRs merged without review, and low code churn all help drive better code quality.
Ready to improve the quality
of your code?

3. Set your goals
Once you’ve established a baseline with the team, it’s time to dig in.
Unfortunately, you can’t just benchmark your way to better code quality.
Each team needs to come up with a definition of good code quality. For example:
Unfortunately, you can’t just benchmark your way to better code quality.
Each team needs to come up with a definition of good code quality. For example:
PRs under 400 changes
Code churn <11%
2-4 comments per review (when appropriate)
Then you need to establish a working agreement together for the goals you want to meet leveraging the team’s leading and lagging indicators.
Fortunately, LinearB isn’t here to just give you metrics, it gives you the tools to take action and improve. Teams can set customized goals and use them as a guidepost at every ceremony to ensure alignment and keep everyone on track.
Fortunately, LinearB isn’t here to just give you metrics, it gives you the tools to take action and improve. Teams can set customized goals and use them as a guidepost at every ceremony to ensure alignment and keep everyone on track.
4. Automate improvement
Developers and individual contributors are the agents of change (and improvement) in engineering organizations.
WorkerB is the online vehicle for driving improvement across your development teams. This automated bot - designed specifically for developers - alerts teams to events that can negatively impact code quality (and other KPIs like Cycle Time) and what action needs to be taken, like:
WorkerB is the online vehicle for driving improvement across your development teams. This automated bot - designed specifically for developers - alerts teams to events that can negatively impact code quality (and other KPIs like Cycle Time) and what action needs to be taken, like:
Work at risk (>100 changes with a high rework rate)
Hanging PR reviews
Unlinked branches
PRs merged with shallow or no review
Long reviews
Good code quality serves as the foundation for engineering excellence -improve it and watch other engineering team KPIs improve as well.
Music to everyone’s ears!
Music to everyone’s ears!

5. Surface and celebrate code quality improvement
Once implemented, LinearB helps curb bad habits and drive better practices. Metrics that align to code quality will improve and these successes can be shared offline at recurring ceremonies.
Bring up the following wins at your daily standups and post-sprint retros:
Bring up the following wins at your daily standups and post-sprint retros:
Smaller PRs
Deeper reviews
Fewer PRs merged with shallow or no review
Less code churn
You can then bring up longer term successes in executive checkins, things like:
Improved cycle time
Increased functional story investments
More features shipped
Higher planning accuracy and value delivery
You can then bring up longer term successes in executive checkins, things like:
Rinse and repeat!