4 ms·

This post sounds like wisdom, but after looking at it hard, it seems that the point is no more than "peer review processes are popular". Not to say that code r

by rdw 5y ago

This post sounds like wisdom, but after looking at it hard, it seems that the point is no more than "peer review processes are popular". Not to say that code review is bad in any way (I do it at my current role), but, this argument for them is not very good. One downside of code review is reduced velocity. There are teams out there who use code review so effectively that they never ship big fuck-ups to production. They never have to tell clients that they have bad practices. Instead, they struggle to get clients because they pay much more per line of code shipped and therefore don't deliver as good of a value as their competitors. This where the argument needs to be: whether and how to have code reviews be a net positive.

ljm 5y ago
Ultimately I think it's down to where you want to pay for that decision (for want of a better term), or where to put the bottleneck. I think that putting the bottleneck in production (which would block all work unrelated to a fix if a catastrophic fuckup took place) might as well be a hedge against the possibility of things fucking up so badly in a given timeframe. You could also make code review a bottleneck, but I haven't seen that work well in practice compared to putting it at QA or as part of a release process (unless you combine them in a continuous delivery workflow). I can see how that equation balances in favour of no code review when it's in the context of a startup that is probably still figuring out how to make money, especially with a subscription based app launcher. As far as prototyping and early stage iterations go, you're probably just seeing what works and reviewing the code isn't so important at that point. There would still be one or two things you'd ask someone to check, e.g. security related stuff. I think you make a good point though: what makes an effective code review process? I don't think there's a single answer to that because it depends on the circumstances. I would at least say that it goes better if it's treated as a priority and issues are raised and dealt with promptly, rather than leaving it as a chore you eventually get around to. And you would have to see value in it beyond it being a sanity check, as others in this thread have described (knowledge transfer, for example).
baron816 5y ago
I'd argue that social proof often makes for a good argument. Perhaps not the best argument, but still a good one. "Best practices" still carry weight. Of course you can make an argument that the thing everyone does is wrong, and win. That's happened millions of times in this industry. But if the argument is nearly strictly between "this is what everyone does" vs "this is what I do", the former is going to win.

by rdw 5y ago

ljm 5y ago

Ultimately I think it's down to where you want to pay for that decision (for want of a better term), or where to put the bottleneck. I think that putting the bottleneck in production (which would block all work unrelated to a fix if a catastrophic fuckup took place) might as well be a hedge against the possibility of things fucking up so badly in a given timeframe. You could also make code review a bottleneck, but I haven't seen that work well in practice compared to putting it at QA or as part of a release process (unless you combine them in a continuous delivery workflow). I can see how that equation balances in favour of no code review when it's in the context of a startup that is probably still figuring out how to make money, especially with a subscription based app launcher. As far as prototyping and early stage iterations go, you're probably just seeing what works and reviewing the code isn't so important at that point. There would still be one or two things you'd ask someone to check, e.g. security related stuff. I think you make a good point though: what makes an effective code review process? I don't think there's a single answer to that because it depends on the circumstances. I would at least say that it goes better if it's treated as a priority and issues are raised and dealt with promptly, rather than leaving it as a chore you eventually get around to. And you would have to see value in it beyond it being a sanity check, as others in this thread have described (knowledge transfer, for example).

baron816 5y ago

I'd argue that social proof often makes for a good argument. Perhaps not the best argument, but still a good one. "Best practices" still carry weight. Of course you can make an argument that the thing everyone does is wrong, and win. That's happened millions of times in this industry. But if the argument is nearly strictly between "this is what everyone does" vs "this is what I do", the former is going to win.