[andydavieswork]

> In order to do Big Stuff, you need a Big Team.

Depends on your definition of Big Stuff. If you mean send a rocket to Mars, then yes. But the vast majority of us are working on simple web apps that might call a few apis, yet these seem to require Big Teams. Compare that to what a single game developer might produce, and compare the complexity and performance of the product.

I think we need Big Teams for Small Stuff precisely _because_ of these 'modern development practices' that you mention. Getting things done in these paradigms takes _forever_, so you need a Big Team.

[ChrisMarshallNY]

That's true. Like I said, I can only speak from my experience.

I do think that we are in a sort of "dependency hell," that is sorting itself out. In the end, a few really good dependencies will still be standing in the blasted wasteland.

Dependencies mean that a small team can do Big Stuff, but that relies on the dependency being good.

"Good" means a lot of things. Low bug count is one metric, but so is clear documentation, community support, developer support, and even tribal knowledge. It doesn't necessarily mean "buzzword-compliant," but sometimes aligning to modern "buzz" means that it benefits from the tribal knowledge that exists for that term, and you can deprecate some things like documentation and training.

People often think that I'm a dependency curmudgeon. I'm not. I am, however, a dependency skeptic.

I will rely on operating system frameworks and utilities almost without question, but I won't just add any old data processor to my project because it's "cool." I need to be convinced that it has good quality, good support, and a high "bus coefficient," not to mention that it meets my needs, and doesn't introduce a lot of extra overhead.

Nothing sucks more than building a system, based on a subsystem that disintegrates a year down the road. I suspect many folks that have built systems based on various Google tech, can relate. I have had that experience with Apple tech, over the years (Can you say "OpenDoc"? I knew you could!).

[chiefalchemist]

> I think we need Big Teams for Small Stuff precisely _because_ of these 'modern development practices' that you mention.

Perhaps. But what I've also seen is the head count of a given project is a direct reflection of the intra-org status of the person heading the project.

There's a belief - that's a myth - that if 3 ppl is good the 6 is twice as good and time will be cut in half. I think we also know - with rare exception - that productivity slides as heads increase.

That's a given.

Then there's also a belief - again a myth - that some mod dev practices can fix the increased head count issue. It might mitigate it here and there. But MDP can only do so much to fix a dysfunctional org/group.

Ultimately it's a leadership/management issue. Process and technology are too often lipstick on a pig.

[pjc50]

> There's a belief - that's a myth - that if 3 ppl is good the 6 is twice as good and time will be cut in half. I think we also know - with rare exception - that productivity slides as heads increase.

This goes back to Brooks and has been true since longer than most of the programming industry has been alive. I do wonder why people are so resistant to learning from the past and just assuming "the way we do things now" must be an improvement.

[wehadfun]

> that if 3 ppl is good the 6 is twice as good

This 6 person development team is promoted by the Agile Industry. They say 6 people is a sweet spot, so that if someone goes on vacation then some other developer can "cover" them.

[chiefalchemist]

Yes. I should have said 6 and 12 or more. That said, it was only a quick refernce to the fact that productions drags as head count increases.