--- title: "A Value System for Code Reviews, and How to Scale Them for a Large Project" url: "https://www.5whys.com/articles/a-value-system-for-code-reviews-and-how-to-scale-them-for-a.md" canonical: "https://www.5whys.com/articles/a-value-system-for-code-reviews-and-how-to-scale-them-for-a.html" published: "2014-09-18T14:16:44.583000+00:00" updated: "2015-01-02T07:56:18.086000+00:00" tags: ["First Steps during chaos", "Growing People"] author: "Roy Osherove" description: "One of my customers wanted my help is increasing their code quality. When I spoke with the developers the following conversation happened several times: Me: \"Wow, this code... how many lines long is this method?\" Dev: \"about 700. Yeah I…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # A Value System for Code Reviews, and How to Scale Them for a Large Project One of my customers wanted my help is increasing their code quality. When I spoke with the developers the following conversation happened several times: _Me: "Wow, this code... how many lines long is this method?"_ _Dev: "about 700. Yeah I know"_ _Me: "Have you tried to refactor some of it?"_ _Dev: "oh.. noooo."_ _Me: "What if we just extract this small part over here , these couple of lines, to a method with a good name?"_ _Dev: "Yeah, let's not.  If I do that then I have to do a code review on that, and that can take 24 hours to 3 days. The architects are so busy.. too much of a big deal. I'd rather focus on what I'm doing"_ When I went to the architects I heard from them how overworked they were. They meant well, but 2 architects on 30 devs, with more of their own stuff to do as well.. it just didn't scale. I went to the chief Architect and told him what I saw. I told him I felt that the way the code review process worked (reviews are done through a tool, and take very long) is actually deterring people from changing the code for the better. He was surprised to hear it. After all, they had instituted mandatory code reviews to _increase_ code quality. So we talked about what we can do. Here's the plan we setup in place: We will organize a team meeting of all the architect where we will agree on some basic values of what we want from code reviews. I noted that the following values worked for me: A code review is successful if: - The developer who wrote the code learned something new (even if small) - The code ends up being better  (even if slightly, even if it's just one character or a name change) - To achieve this, an effective code review [has to be in person](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html), not through a tool if possible. if not, then through a non text tool (visual+ audio) - It also has to occur quickly , or even immediately when the code is ready for check in - It increases the amount of people that can review code, or the amount of code they can review well We decided to experiment for a couple of months with doing reviews this way: - When a developer needs a code review, they can just go to an architect and ask for it in person (not using a tool hopefully). - The architect will join the dev and review the code, while talking as much as possible about their thinking process, coaching in the process - A THIRD person will join (another dev) the review, sitting near and learning how to review the code. - The next time a review is requested, the learning dev (third person) will try and do the review while the architect sits back and sees how it goes, then goes over any missing things with the reviewer  - Developers will check in **early** and **often** so that code reviews are nice and short (a few minutes hopefully) In this way we: 1. Make the reviews more effective since they are in person 2. Less bureaucratic since they happen very quickly 3. This also  makes developers less afraid to change code and get feedback on it since it doesn't take a long time 4. We make more developers able to be code reviewers, thus making the code review process more scalable. Anyone can review anyone's code within a couple of months. I wrote more about [code reviews in the face of horrible code quality here.](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/