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

251–260 of 339 posts

Re: Every layer of review makes you 10x slower

#251

Post by pdhborges »

Swizec wrote: post #236
pdhborges wrote: post #95

Earlier quoted context omitted.

> The other side of this is building safety nets. Takes ~10min to revert a bad deploy. Does it? Reverting a bad deploy is not only about running the previous version. Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?

> Does it? Reverting a bad deploy is not only about running the previous version. It does. We’ve tried. No it’s not as easy as running the previous version. I have written about this: https://swizec.com/blog/why-software-only-moves-forward/

I read the article and to be honest I don't know where we disagree. I disagree with this quote,

> Takes ~10min to revert a bad deploy

A bad deploy can take way over that just in customer or partner management communication.

Re: Every layer of review makes you 10x slower

#252

Post by QuiEgo »

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…

> your reviews are there to check someone has done their job well enough then you have bigger problems

Welcome to working with real people. They go off the rails and ignore everything you’ve agreed to during design because they get lazy or feel schedule pressure and cut corners all the time.

Sideline: I feel like AI obeys the spec better than engineers sometimes sigh.

Re: Every layer of review makes you 10x slower

#253

Post by christophilus »

Hendrikto wrote: post #209
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'm not convinced there's any real velocity gains in agile when factoring in all the fiddling, rewrites, and refactoring. That’s not the point. The point is to end up with something actually useful in the end. If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it. The reason waterfall methodology falls flat so often is not long delivery times, but ending up with compl…

> If the artifact I deliver does not meet requirements, it does not really matter how fast I deliver it.

I don’t know. The faster you deliver the wrong thing, the sooner you can discover your mistake and pivot.

Re: Every layer of review makes you 10x slower

#254

Post by jerf »

beepbooptheory wrote: post #212
pu_pe wrote: post #100

Nice piece, and rings true. I also think startups and smaller organizations will be able to capture better value out of AI because they simply don't have all those approval layers.

I do not think you have comprehended the blog. > you can’t overcome latency with brute force Curious what rang true to you if not the main point?

The approval tree grows logarithmically as the size of the company grows. A startup can win initially because they may have zero or one level to get to production. That's part of how they manage to get inside the OODA loop of much bigger companies.

The flip side of that, and why the software world is not a complex network of millions of tiny startups but in fact has quite a few companies where log(organization) >= 2, is that there are a lot of tasks that are just larger than a startup, and the log of the minimum size organization that can do the job becomes 2 or 3 or 4.

There is certainly at least the possibility that AI can really enhance those startups even faster, but it also means that they'll get to the point that they need more layers more quickly, too. Since AI can help much, much more with coding than it can with the other layers (not that it can't help, but at the moment I don't think there's anybody else in the world getting the advantages from AI that programmers are getting), it can also result in the amount of time that startups can stay in the log(organization)=1 range shrink.

(Pardon the sloppy "log(organization)" notation. It should not be taken too literally.)

Re: Every layer of review makes you 10x slower

#255

Post by frandroid »

For all the people talking about 5 hour PR review delays... This reminds me of some teams that rotate the "fire extinguisher/emergency bug fixer" duty every day/week/sprint to a different developer. One could rotate a dedicated "first review duty" person. That developer would be in charge of focusing on rapidly starting PR reviews as their priority, with option to request other reviewers if necessary. Spreading the duty around would make people be respectful of the reviewer because if they send unreviewed slop to the reviewers, it's likely that people will send them slop too.

Re: Every layer of review makes you 10x slower

#256

Post by ge96 »

riffraff wrote: post #34

> Code a simple bug fix 30 minutes > Get it code reviewed by the peer next to you 300 minutes → 5 hours → half a day Is it takes 5 hours for a peer to review a simple bugfix your operation is dysfunctional.

Hehe I'm waiting right now, should have been reviewed yesterday but I'm like alright, I'll just chill then.

Re: Every layer of review makes you 10x slower

#257

Post by marcosdumay »

steveBK123 wrote: post #178
zingar wrote: post #166

Earlier quoted context omitted.

It’s possible to manage the quarterly expectations by saying “we can improve metric X by 10% in a quarter”. It’s often possible to find an improvement that you’re very confident of making very quickly. Depending on how backwards the company is you may need to hide the fact that the 10% improvement required a one line change after a month of experimentation, or they’ll fight you on the experimentation time and expect…

My experience in an agile firm was that they hired a lot of experienced people and then treated them like juniors. Actively allergic to thinking ahead. To get around the problem that deliverables took more than a few days, actual tasks would be salami sliced down into 3 point tickets that simply delivered the starting state the next ticket needed. None of these tickets being completed was an actual user observable de…

> and then treated them like juniors

You shouldn't put juniors in a strict short time box either. At least not for long.

People don't grow if they can't think about the results of their work. If if your juniors can't grow, you could as well not hire any.

Re: Every layer of review makes you 10x slower

#258

Post by AndrewDucker »

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…

Agile largely came about because we thought about where we wanted the product to go, and the steps to get there, and started building, and then it turned out that the way we thought we wanted to go was wrong, and all of that planning we did was completely wasted.

If you work in an environment where you definitely do know where you want the product to go, and the customer doesn't change their mind once they've seen the first working bits, then great. But I've never worked in that kind of environment.

Re: Every layer of review makes you 10x slower

#259

Post by budman1 »

orthoxerox wrote: post #181
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…

> 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. That's an interesting observation. That's one of the biggest criticisms of waterfall: by the time you finish building something the requirements have changed already, so you have to rewrite it.

there is a difference between the requirements changing and the poor quality, quickly made implementation proves to be inadequate.

agile approaches are based on the quick implementations, redone as needed.

my favorite life cycle: 1> Start with requirements identification for the entire system. 2> Pick a subset of requirements to implement and demonstrate (or deliver) to the customer. 3> Refine the requirements as needed. 4> go to 2

The key is you have an idea of overall system requirements and what is needed, in the end, for the software you are writing. Thus the re-factoring, and re-design due to things not included in the sprint do not occur. (or occur less)

Re: Every layer of review makes you 10x slower

#260

Post by budman1 »

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.

But if you don't know what you are making, it is the only option!
Post reply on HN