4 ms·
> To this day I can't quite fathom how 300 developers work on the same thing. Yep... As someone who's been in this situation a few times: after a certain numbe
by ratww 5y ago
> To this day I can't quite fathom how 300 developers work on the same thing.
Yep... As someone who's been in this situation a few times: after a certain number, very badly. Things get done, but in slower and messier pace than at a smaller company.
The diminishing returns law kicks in together with sunken cost fallacy. With 10 people you're slow, with 50 you're fast, but then there and you're forever "chasing that high" of velocity increasing with headcount.
There's no way to escape what Brooks wrote in Mythical Man Month.
Unless there is a very clear-cut division of labour, like 20 teams working in 20 different libraries that don't talk to each other, there is no free lunch when it comes to team communication.
- hinkley 5y agoEven with four teams, I've found a lot of instances of people building the same thing. That wouldn't necessarily be bad, except often those 'things' fall into a space of errors that almost everyone makes until they learn/are taught to stop doing it. So you notice that there are 2.5 implementations of a bit of logic because there are bugs, maybe security bugs, that cross 2 of them or are different on each. I have found that once the code exceeds the size of one brain, it accelerates because if I don't know code exists, I will write it again. Like driving down a mountain side with the brakes on the whole way, eventually the sanity leaves the system and you go careening down the mountain.