How satisfied are you with the quality of software you help build?
That was one of the burning questions we asked more than 600 software professionals in our State of Code Quality 2016 survey.
It’s a question that dev teams are being asked to answer on a continuous basis. In a world where everything runs on software, quality has never been more important.
So, what did we find out?
We surveyed participants from dev teams ranging from less than 5 employees to 50+, and across the board software sentiment was positive.
In fact, 67% of participants said they either agree (53%) or strongly agree (14%) that they are satisfied. Just 10% of respondents felt negatively about the quality of software they help build.
But despite the overall positive sentiment, there was still certainly room for improvement, as one-third of participants were unwilling to say that they felt positively about the quality of software they help build.
So, how are teams improving the quality of the software they help build?
When it comes to code quality, participants agree that code review is the number one method for improving code quality. Unit testing (19%) and functional testing (13%) are also seen as being critical to code quality.
Code review is by no means a new process for development teams looking to improve code quality. But in 2016, it’s clear that teams understand its importance more than ever before.
In fact, when asked specifically about the biggest benefits of doing code reviews, we found that:
- 90% said improve code quality
- 72% said sharing knowledge across the team
- 59% said enhanced maintainability of code
- 56% said ability to mentor less experienced developers
- 49% said adherence to coding standards
From improve quality and maintainability to shared knowledge and collaboration — teams are seeing a wide range of benefits from regularly performing code reviews.
What does code review look like in a modern development team?
For a majority of teams, code review is still an ad-hoc process, with 90% of participants doing “over the shoulder” code review.
Along with the ad-hoc approach, 63% are also doing tool-based code review, while 53% are doing meeting-based reviews.
How do these different methods stack up when it comes to code quality?
Respondents who said they were doing tool-based code review felt the most positively about the quality of software they help build. Participants who are only doing ad-hoc reviews felt the least positive and were more likely to disagree that they felt positively about their software quality.
We also found that teams who are doing tool-based code review are doing code reviews more often — 26.3% of respondents are doing tool-based cove review on a daily basis, compared to 14% for meeting-based code review, and less than 5% for ad-hoc code reviews.
Despite the increased focus on quality and the understanding of how code review can help teams build better software — teams still face obstacles when implementing code review.
The three biggest obstacles facing teams include:
- Workload (66%)
- Deadline/Time Constraints (44%)
- Lack of staffing (39%)
Overcoming these challenges will be critical for organizations that want to improve software quality in 2016 and beyond.
While workload, time, and budget will always be top concerns for development teams, prioritizing code reviews has proven to increase code quality and help teams work more efficiently together.
The State of Code Quality 2016
The State of Code Review 2016 Report includes valuable insights into how development teams are collaborating to improve code quality in 2016.
In addition to code review, the report provides insight on the different tools teams are using to build and maintain software. The report also takes a deeper look at how development teams are organized in 2016 and how dev teams in organizations ranging from less than 5 employees to more 10,000 are approaching code quality.
Get the report!
