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.
High code quality should be a priority for development shops. Why? Higher code quality means:
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.
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:
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?
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:
Bottom line: Smaller PRs, deeper reviews, and an absence of PRs merged without review, and low code churn all help drive better code quality.
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:
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.
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:
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!
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:
You can then bring up longer term successes in executive checkins, things like:
Rinse and repeat!
Check out how to use LinearB to plan iterations more accurately
Learn more about Cycle Timeand how to reduce yours with LinearB