Editorial note: I originally wrote this post for the SmartBear blog. Go to their site and check out the original! If you like this post, there are a lot of good ones there by a variety of authors, on topics like code review, API design, testing, and more.
Here’s a thought exercise for you. Should non-technical people participate in code reviews?
It’s off the beaten path, to be sure, but I think it’s an interesting philosophical consideration. We’re entirely used to code review as an exercise by developers and for developers. But is there a place or purpose for outsiders to review our code?
Why do it?
I’ll state up front my answer to that question: “yes, provided it happens in a specific, directed way.” But to convince you, let me offer some potential benefits that I see, depending on who reviews what.
- In general, it could bring members of the team with different skill sets closer together. Developers learn the business domain; why not let the business people understand the developers’ world?
- This could serve as a sanity check. Are developers writing code that accurately reflects the domain?
- It could also force developers to write code that is cleaner, more readable, and more maintainable. Imagine having to write code that a non-technical person might understand.
I’ll offer more detailed rationale for this thinking shortly. But I imagine you’d agree that these goals would be worth pursuing. If an occasional, different style of code review can help, then it’d be worth doing.
Be careful with this.
But before I talk about what these reviews might look like and how they could help, it’s important to stress that I’m not proposing a radical change to the code review process. What I’m proposing is an occasional exercise to offer a different perspective on the team’s code. Having non-technical folks look at the code shouldn’t be a vehicle for micromanagement or for former techies to quibble over code. It shouldn’t be exhaustive, since a lot of plumbing code will be nonsense to them.