Hacker News Reader

Comment by dbolgheroni | Hacker News Reader

Code review is another sacred process that seems too good not to have, but many teams use it as a "we care about quality" stamp when in fact they do not. Used for just nitpicking code style (important but not the whole reason to have CR, and there are tools for this), issue comments like "LGTM" and approve whatever arrives at the pull request anyway.

View on HN

I've not yet seen code review implemented in a good way in places I have worked. It's not really considered "real work" (may result in zero lines of code change) and it takes time to properly read through code and figuring out where the weaknesses might be. I just end up being forced to skim read for anything obvious and merging, because there is not enough time to review the code properly.

As a manager, code review has two benefits that typically matter to me: (a) cost: it's cheaper to fix a defect that hasn't shipped (reading tests for missing cases is a useful review, in my experience); (b) bus-factor: make sure someone else has a passing familiarity with the code. And some ancillary (and somewhat performative benefits) like compliance: your iso-27001, soc-2 change control processes likely require a review.

It's hard, though, to keep code reviews from turning into style and architecture reviews. Code reviewing for style is subjective. (And if someone on the team regularly produces very poor quality code, code review isn't the vehicle for fixing that.) Code reviewing for architecture is expensive; settle on a design before producing production-ready code.

My $0.02 from the other side of the manager/programmer fence.

Out of interest, how are you using code reviews to be ISO-27001 compliant?

ISO-27001's change management process requires that [you have and a execute a change management policy that requires that] changes are conducted as planned, that changes are evaluated for impact, and are authorized. In my experience, auditors will accept peer-review as a component of your change management procedure as a meaningful contributor to meeting these requirements.

"All changes are reviewed by a subject matter expert who verifies that the change meets the planned activity as described in the associated issue/ticket. Changes are not deployed to production environments until authorized by a subject matter expert after review. An independent reviewer evaluates changes for production impact before the change is deployed..."

If you are doing code review already, might as well leverage it here.

Code review where I worked seem to either in practice be rubber stamping or back scratching. Never once have I felt the need for it. If people are unsure about a change they ask usually.

If teams care about each other’s code, they ought to collaborate on its design and implementation from the start. I’ve come to see code reviews (as a gate at the end of some cycle) as an abdication of responsibility and the worst possible way to achieve alignment and high quality. Any team that gets to the end of a feature without confidence that it can be immediately rolled out to create value for users has a fundamentally flawed process.

> they ought to collaborate on its design and implementation from the start

That's exactly right. After said process, it comes down to trusting your coworkers to execute capably. And if you don't think coworker is capable, say so (or if they're junior, more prudently hand them the simpler tasks — perhaps code review behind their back and let it go if the code is "valid" — even if it is not the Best Way™ in your opinion.)

Reply on news.ycombinator.com