Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Every layer of review makes you 10x slower

apenwarr.ca

Post reply on HN
Print view View original

191–200 of 339 posts

Re: Every layer of review makes you 10x slower

#191

Post by nottorp »

steveBK123 wrote: post #157
2OEH8eoCRo0 wrote: post #154

Earlier quoted context omitted.

I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fid…

> I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times. My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for…

There's an abstraction level above which waterfall makes more sense, and below which [some replacement for agile but without the rituals] makes more sense.

Re: Every layer of review makes you 10x slower

#192

Post by krilcebre »

ivanjermakov wrote: post #86
lelanthran wrote: post #12

I wonder where the reviewer worked where PRs are addressed in 5 hours. IME it's measured in units of days, not hours. I agree with him anyway: if every dev felt comfortable hitting a stop button to fix a bug then reviewing might not be needed. The reality is that any individual dev will get dinged for not meeting a release objective.

I'm yet to see a project where reviews are handled seriously. Both business and developers couldn't care less.

I have, and in each sprint we always had tickets for reviewing the implementation, which could take anywhere from an hour to 2 days.

The code quality was much better than in my current workplace where the reviews are done in minutes, although the software was also orders of magnitude more complex.

Re: Every layer of review makes you 10x slower

#193

Post by webpolis »

simonw wrote: post #11

This is one of the reasons I'm so interested in sandboxing. A great way to reduce the need for review is to have ways of running code that limit the blast radius if the code is bad. Running code in a sandbox can mean that the worst that can happen is a bad output as opposed to a memory leak, security hole or worse.

[dead]

Re: Every layer of review makes you 10x slower

#194

Post by steveBK123 »

nottorp wrote: post #191
steveBK123 wrote: post #157

Earlier quoted context omitted.

> I've worked waterfall and while I hated it at the time I'd rather go back to it. Today we move much faster but build the wrong thing or rewrite and refactor things multiple times. My experience as well. Waterfall is like - let's think about where we want this product to go, and the steps to get there. Agile is like ADHD addled zig zag journey to a destination cutting corners because we are rewriting a component for…

There's an abstraction level above which waterfall makes more sense, and below which [some replacement for agile but without the rituals] makes more sense.

I think Qs to ask are.. if the nature of user facing deliverable tasks are longer than a sprint, the tasks have linear dependencies, there are coordination concerns, etc

Re: Every layer of review makes you 10x slower

#195

Post by goalieca »

2OEH8eoCRo0 wrote: post #154
alkonaut wrote: post #107

Earlier quoted context omitted.

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement. If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's pl…

I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fid…

Agile is for when you don't know what you're making and you're basically improvising. People forget that.

Re: Every layer of review makes you 10x slower

#197

Post by steveBK123 »

goalieca wrote: post #195
2OEH8eoCRo0 wrote: post #154

Earlier quoted context omitted.

I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fid…

Agile is for when you don't know what you're making and you're basically improvising. People forget that.

Correct, and it was applied top-down to teams that do larger infrastructure / implementations in known areas / etc.

There are costs to pouring out a cement foundation without thinking through how many floors your building is going to be in advance.

Re: Every layer of review makes you 10x slower

#198

Post by g947o »

anal_reactor wrote: post #32
onion2k wrote: post #22

But you can’t just not review things! Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team wh…

I never review PRs, I always rubber-stamp them, unless they come from a certified idiot: 1. I don't care because the company at large fails to value quality engineering. 2. 90% of PR comments are arguments about variable names. 3. The other 10% are mistakes that have very limited blast radius. It's just that, unless my coworker is a complete moron, then most likely whatever they came up with is at least in acceptable…

That seems a lot about the company and the culture rather than about how code review is supposed to work.

I have been involved in enough code reviews both in a corporate environment and in open source projects to know this is an outlier. When code review is done well, both the author and reviewer learn from the experience.

Re: Every layer of review makes you 10x slower

#199

Post by alkonaut »

2OEH8eoCRo0 wrote: post #154
alkonaut wrote: post #107

Earlier quoted context omitted.

This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement. If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's pl…

I've worked waterfall (defense) and while I hated it at the time I'd rather go back to it. Today we move much faster but often build the wrong thing or rewrite and refactor things multiple times. In waterfall we move glacially but what we would build sticks. Also, with so much up front planning the code practically writes itself. I'm not convinced there's any real velocity gains in agile when factoring in all the fid…

I think it also depends on how people think. I might be able to sit can't sit in a meeting room/white board/documentation editor and come up with what the big problems is (where pain points in implementation will occur, where a sudden quadratic algorithm pops up, where a cache invalidation becomes impossible, ...) even if I stare at this white board or discuss with my peers for days.

But when I hammer out the first 30 minutes of code, I have that info. And if we just spent four 2-hour meetings discussing this design, it's very common that I after 30 minutes of coding either have found 5 things that makes this design completly infeasible, or maybe 2 things that would have been so good to know before the meeting, that the 8 hours of meetings just should not have happened.

They should have been a single 2 hour meeting, followed by 30 minutes of coding, then a second 2 hour meeting to discuss the discoveries. Others might be much better than me of discovering these things at the design stage, but to me coding is the design stage. It's when I step back and say "wait a minute, this won't work!".

Post reply on HN