upvote

points

by MadxX7912 hours ago |
comments
upvoteby steveklabnik6 hours ago|
next
[-]
I know you're being sarcastic, but this is what OpenAI has said:

https://openai.com/index/harness-engineering/

> This translates to an average throughput of 3.5 PRs per engineer per day, and surprisingly the throughput has increased as the team has grown to now seven engineers.

We will see if this continues to scale up!

reply
upvoteby smikhanov11 hours ago|
prev|
[-]
That law (formulated in the 70s, I’ll remind the reader) wasn’t true for at least couple decades now.
reply
upvoteby medi8r11 hours ago|
parent|
[-]
Why not? What changed? It seems like a human factors thing. New people have to get up to speed. Doers become trainers.
reply
upvoteby smikhanov11 hours ago|
parent|
[-]
Several related reasons working at once. The nature of work changed. The boundary between accidental and incidental complexity shifted (and it’s unclear whether this distinction still exists). Niche specializations within the field emerged. The way to structure and decompose projects changed dramatically (agile and stuff).

One pathological example: if you’re running a server-based product, quite often what stands between you and a new feature launch is literally couple of thousands of lines of Kubernetes YAML. Would adding someone who’s proficient in Kubernetes slow you down? Of course not.

One may say, hey, this is just the server-side Kubernetes-based development being insane, and I’ll say, the whole modern business of software development is like this.

reply
upvoteby medi8r11 hours ago|
parent|
[-]
Hmm interesting, thanks! I was ready to argue but now I have to think, which is even better.
reply
upvoteby smikhanov11 hours ago|
parent|
[-]
That’s a lovely comment, thank you. If you’re keen to think about it more, consider the fact that the existing members of the project that’s being late are actually in not as much of an advantage compared to the new joiners, as it’s common to think.

Yes, they know how the feature they work on relates to other features, but actually implementing that feature is very often mostly involves fighting with technology, wrangling the entire stack into the shape you need.

In Brooks’s times the stack was paper-thin, almost nonexistent. In modern times it’s not, and adding someone who knows the technology, but doesn’t have the domain knowledge related to your feature still helps you. It doesn’t slow you down.

One may argue that I’m again pointing to the difference between accidental and incidental complexity, and my argument is essentially “accidental complexity takes over”, but accidental complexity actually does influence your feature too, by defining what’s possible and what’s not.

Some good thoughts (not mine) on the modern boundary between accidental and incidental complexity: https://danluu.com/essential-complexity/

reply
upvoteby dasil0039 hours ago|
parent|
[-]
I sort of agree that the surface area and incidental complexity of stacks give more space to plug more developers in than was true in the 70s and 80s. But I disagree strongly this invalidates Brooks Law. Certainly there are cases where adding people helps, especially if they are stronger engineers than the ones that are already there, but I’ve also seen way too many projects devolve into resourcing conversations when the real problem was over-complicated, poorly reasoned requirements, boil-the-ocean solutions promising a perfect end state without a clear plan to get there iteratively.
reply
upvoteby ldng9 hours ago|
parent|
[-]
Plus, the "since there are more resources, let's add features" effect.
reply