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

311–320 of 339 posts

Re: Every layer of review makes you 10x slower

#311

Post by gunsle »

alkonaut wrote: post #107
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…

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…

Agreed completely. I’ve worked at a couple places that want to design session everything to death and then meticulously convert that design by committee into story requirements to the point that no actual engineering is even needed from the engineer. On top of that, the usual problem occurs - turns out there actually was a lot of unknowns, and now that 2-4 hours you spent with 5-10 other people meticulously crafting the story and execution plan has been completely wasted as the requirements and design shift by extension. It infuriates me to no end that others within the org don’t see how frequently we do redo these meticulously written stories and what a waste of time that is.

Re: Every layer of review makes you 10x slower

#312

Post by joshmoody24 »

alkonaut wrote: post #104

I think this makes an assumption early on which is that things are serialized, when usually they are not. If I complete a bugfix every 30 minutes, and submit them all for review, then I really don't care whether the review completes 5 hours later. By that time I have fixed 10 more bugs! Sure, getting review feedback 5 hours later will force me to context switch back to 10 bugs ago and try to remember what that was ab…

I made a queuing theory calculator for this: https://joshmoody.org/blog/number-of-agents/#number-of-agent...

Although you'll have to mentally replace the word "agent" with "PR" for it to make sense in this context. The math is the same. It all boils down to how much those context switches costs you. If it's a large cost, then you can get a huge productivity boost by increasing review speed.

In the "show calculations" section, the amount of wasted time caused by context switching is the delta between the numbers in the phrase "T_r adjusted from 30.0 to 35 minutes". That number is increases as context switching cost and "average agent time" (AKA "average PR review time") goes up.

Re: Every layer of review makes you 10x slower

#313

Post by schwede »

MrBuddyCasino wrote: post #96
thot_experiment wrote: post #17

Valve is one of the only companies that appears to understand this, as well as that individual productivity is almost always limited by communication bandwidth, and communication burden is exponential as nodes in the tree/mesh grow linearly. [or some derated exponent since it doesn't need to be fully connected]

The first one to realise this was Jeff Bezos, afaik. One would think the others have wisened up in the meantime, but no.

Definitely goes back earlier for software. See the Mythical Man Month… Growing a team imposes a communication cost.

Re: Every layer of review makes you 10x slower

#314

Post by SmashngKbds »

This was well written and it hit hard. It brought clarity to an uneasy collection of gut feels, anecdotal evidence, and fundamental beliefs like nothing else. What I'm feeling might even be categorized as an epiphany.

I've always liked Tailscale as a product and now I might be a fan of their CEO too. Who knew?

I'll be sharing this post widely. Avery - if you're on here, thanks for writing this!

Re: Every layer of review makes you 10x slower

#315

Post by nomel »

pydry wrote: post #248
alkonaut wrote: post #229

Earlier quoted context omitted.

The problem is that you can only meaningfully pair program with programmers. The people involved in architexture/design meetings might not be programmers. The questions that arise when 2 programmers work might not be resolvable without involving the others.

Nonsense. I pair all the time with stakeholders. If you strip out all of the cucumber nonsense this is essentially what BDD is - fleshing out and refining specs by guiding people through concrete, written example scenarios. I also often pair with infrastructure people on solving a problem - e.g. "im trying to do x as per the docs, but if you look at my screen i get an 1003 error code any idea what went wrong?". Or, p…

you're missing the context of this thread. for the purpose of code quality/review, it can only work if the other person is a programmer.

Re: Every layer of review makes you 10x slower

#318

Post by lmm »

JoshTriplett wrote: post #68
seer wrote: post #47

Earlier quoted context omitted.

I think what they meant is you “can save 10 hours of planning with one hour of doing” And I think this has become even more so with the age of ai, because there is even more unknown unknowns, which is harder to discover while planning, but easy wile “doing” and that “doing” itself is so much more streamlined. In my experience no amount of planning will de-risk software engineering effort, what works is making sure co…

> I think what they meant is you “can save 10 hours of planning with one hour of doing” I know what they meant, and I also meant the thing I said instead. I have seen many, many people forge ahead on work that could have been saved by a bit more planning. Not overplanning , but doing a reasonable amount of planning. Figuring out where the line is between planning and "just start trying some experiments" is a matter o…

I'm pretty sure I've literally never seen planning deliver value. But interestingly even the environments where planning was most obviously useless rarely diminished people's willingness to defend it.

Re: Every layer of review makes you 10x slower

#319

Post by gwern »

The 10x claim reminds me of various scaling laws in anthropology/sociology, especially the much-debated Haire cube-root scaling law (eg https://gwern.net/doc/sociology/1959-haire.pdf https://gwern.net/doc/economics/1983-stephan.pdf ). I wonder if one could give a derivation from queuing theory where you have an argument along the lines of 'in indefinitely many layers of queues of queues, the total delay is minimized at 90% load per queue which yields a 10x scale-free slowdown'?

Re: Every layer of review makes you 10x slower

#320

Post by bfivyvysj »

I've been banging on a drum for the past decade that the industry needs to switch to asynchronous review.

You allow self review and optional external review of code but the default is that the engineer can ship to production without a review block.

Then you either do post merge review: have a review column in jira or whatever where people are assigned to review and can complete on their own schedule in a non disruptive and non blocking way. This also avoids piling reviews onto whoever has the best rubber stamp.

Or

You switch to a quarterly system review meeting where you as a group go over and suggest improvements to make in the codebase holistically.

I've seen both of these work extremely well and with AI you can basically automate the review process to the point it's pretty much pointless having a human review step.

The only other way to avoid the issue of people sitting on thumbs waiting for review is to have everyone prioritize reviewing code ahead of producing new code. This works but is incredibly disruptive to the reviewer and has side effects like review bombing on the largest rubber stamp reviewer.

Post reply on HN