Member-only story
Code review has become an indispensable part of any mature software development process. The Internet is awash in information on the benefits of code review, and how to do it. We won’t go over that ground again here.
Code reviews are great. The problem is that by the time something reaches the point of code review, it can be too late. At that point, it’s often too hard to throw away work based on a flawed design, especially when stakeholders have been assured that some feature “is almost done” (or even been shown a demo), or someone is on the hook for a delivery by the end of the sprint.
It’s not only that code review comes too late in the process to identify design flaws, much less rectify them. It’s also that code review, as currently practiced, does not even target design to start with. Reviewers face a wall of code and diffs and are told to do a “code review”, so that is what they do, namely look at lines of code — rather than looking at the underlying structure of the solution , or in other words, its design.
Every single one of the many benefits attributed to code review, including not only reliability, performance, security, and maintainability, but also socialization, learning, and building a company’s engineering culture, can be gained to an equal or even greater degree from design review…
