Code peer reviews is one of the most mature techniques for quality assurance in software development, first published about as early as the '70s. Yet, we often find they are not used, because people deem them too costly or ineffective. An assessment that directly contradicts our own gut feeling after employing code reviews from day one of our 16-year product history. But what's the truth of it? What are the benefits of code review? Which kinds of issues do they uncover? How do they impact our code? Which factors, such as the reviewing person, influence those results? And ultimately: how much additional time do they actually require?
To answer these and other questions, we analyzed 16 years worth of data from the development of our product Teamscale, from the first prototype to today's enterprise-ready application with 1.5 million SLOC. In my talk, I share our insights and conclusions.
Spoiler alert: We still review all our changes and now feel even better about it ;)