Today we have a guest editorial from Kendra Little as Steve is away on holiday. This editorial was originally published on Feb 7, 2020.

We asked some new questions about code review and change management processes in the 2020 State of Database DevOps report, and the results are quite interesting. One of these new questions asked respondents how easy it is for team members to get code reviews early in the software development process for database changes. We clarified that “early” in the software development process means near the time the change is committed or merged into a main code branch. 

We found that there appears to be a correlation between ease of code review and code quality: those who reported that it’s easy to get a code review (55% of respondents) were much more likely to report that only 1% or less of production deployments cause defects which require a hotfix as compared to other respondent groups who reported higher levels of defects. 

Interestingly, those who find it difficult to get a code review (26% of respondents) reported somewhat higher levels of defects requiring hotfixes than the group of people who respond that they simply don’t have a practice of doing code review at all (16% of respondents).  

Why might this be the case? For those with easy code review, it is likely that review is being done by someone familiar with the application and database domain. If this is the case, it is likely that familiarity helps the reviewer identify potential gotchas or defects in the code early on when the business case is fresh in mind, and the code can be most easily optimized. 

For those who find it difficult to get a code review, the answer is likely more complex: potentially these folks are working across more application and database code bases and are in part less familiar with the codebases than those who don’t have a practice of doing code reviews at all. It may also be that those who don’t have the practice of code review are having architecture planning meetings or discussions instead of code review that provide better design ahead of time – we may wish to study this in more detail in future years to shed further light on this question. 

In any case, this year’s data does suggest that providing an easy mechanism to get code reviews for database changes early in the software development process is associated with higher code quality.  

If you work in a team where it’s difficult or impossible to get a code review, you can begin to make changes to create this culture. 

• Create a community of practice for database development in your organization– basically a user group at work which helps build expertise and relationships across teams. This is a great way to build the body of potential code reviewers 
• Identify team members who you may cross-train with, and regularly code review each other’s changes: while at first, you will not have domain knowledge for each other’s areas, you will quickly build this up with practice
• Establish team members who may build up a specialization in reviewing database changes. These team members should also build up theexpertise to identify specific changes where it is critical to engage with database administrators for code review early