Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why products built by large teams fail so often

blog.mojotech.com

Post reply on HN
Print view View original

11–20 of 43 posts

Re: Why products built by large teams fail so often

#11

Post by kartan »

User23 wrote: post #7

Also, the larger a team is, the more the average ability of the team will approach the average ability of the population it recruits from.

That will mean that most small teams will fail, as they will be composed from average developers. While a few teams will succeed as they have the "extraordinary", whatever that means, developers.

But the reality is that big teams have problems independently of the capacity of the companies to attract talent. So I don't think that "average ability" is the source of the problem.

As someone else posted, The Mythical Man Month is a good read on this area. And communication overhead is an unsolvable problem as the people involved intro a project grows.

Re: Why products built by large teams fail so often

#12

Post by edblarney »

mwfunk wrote: post #8

Generally products built by large teams are large products. There are extra challenges associated with coordinating large groups of people, and there are extra challenges associated with developing big, complicated software products with lots of different subsystems that have to work together. Hopefully no one is using a large team to build a small product. If so, yeah, don't do that. But you're going to get into dif…

There's no 'silver bullet' - but surely a 'large product' does not need to start off as a 'large product'.

A 'small team' making an MVP, and then moving on incrementally from there, adding more people to do peripheral features as the project progress might seem like a good way to overcome some inherent 'monolithic' risks - as well as keep costs down at the start.

It takes an open mind from management to grasp that building complex software is not like building a really big building. You just can't predict outcomes, so, you have to build a good team that can forge a path, and have some 'kill-it-don't-kill-it' guidelines, and expect that many will fail.

Re: Why products built by large teams fail so often

#13

Post by marcosdumay »

kartan wrote: post #11
User23 wrote: post #7

Also, the larger a team is, the more the average ability of the team will approach the average ability of the population it recruits from.

That will mean that most small teams will fail, as they will be composed from average developers. While a few teams will succeed as they have the "extraordinary", whatever that means, developers. But the reality is that big teams have problems independently of the capacity of the companies to attract talent. So I don't think that "average ability" is the source of the problem. As someone else posted, The Mythical Man…

Is there data showing that small teams do indeed fail less often than big teams?

Because, yes, that's completely expected. But our perception is biased so it may not be true.

Re: Why products built by large teams fail so often

#14

Post by cbhl »

edblarney wrote: post #12
mwfunk wrote: post #8

Generally products built by large teams are large products. There are extra challenges associated with coordinating large groups of people, and there are extra challenges associated with developing big, complicated software products with lots of different subsystems that have to work together. Hopefully no one is using a large team to build a small product. If so, yeah, don't do that. But you're going to get into dif…

There's no 'silver bullet' - but surely a 'large product' does not need to start off as a 'large product'. A 'small team' making an MVP, and then moving on incrementally from there, adding more people to do peripheral features as the project progress might seem like a good way to overcome some inherent 'monolithic' risks - as well as keep costs down at the start. It takes an open mind from management to grasp that bu…

Then you run into "rewrite risk" -- that the company won't survive long enough for the MVP to meet the needs of the existing customers.

Re: Why products built by large teams fail so often

#17

Post by kpil »

noxToken wrote: post #15
wizardforhire wrote: post #4

No mention in the article and worth re-iterating... https://en.m.wikipedia.org/wiki/The_Mythical_Man-Month

Non-mobile: https://en.wikipedia.org/wiki/The_Mythical_Man-Month

TMMM contains truly insightful and universally applicable knowledge and insight into building large software systems.

It also contains truly insightful knowledge regarding building operative systems at IBM in the seventies.

It's one of my favourite books on software development. However, it requires some insight and preexisting knowledge from the reader in order to tell what's what.

Re: Why products built by large teams fail so often

#18

Post by maxxxxx »

in my company they first start a project by coming up with a budget, then they hire many people for that budget, then they have a long series of meetings figuring out what the thing should really do. So you have the pressure to get started with a ton of developers while still nobody has a clear vision. These people produce something but usually it's not what you really need.

I would much prefer to have a small team of very good people figuring out things, develop a clear strategy and then see where more people are needed. I think the main evil is to ramp up team size before the team is ready.

Re: Why products built by large teams fail so often

#19

Post by webmaven »

cbhl wrote: post #14
edblarney wrote: post #12

Earlier quoted context omitted.

There's no 'silver bullet' - but surely a 'large product' does not need to start off as a 'large product'. A 'small team' making an MVP, and then moving on incrementally from there, adding more people to do peripheral features as the project progress might seem like a good way to overcome some inherent 'monolithic' risks - as well as keep costs down at the start. It takes an open mind from management to grasp that bu…

Then you run into "rewrite risk" -- that the company won't survive long enough for the MVP to meet the needs of the existing customers.

Or sometimes your prototype or proof-of-concept simply gets deployed to production by executive fiat because they don't understand that it's put together with bubble gum and baling wire, and over the next 3-5 years you are never given the resources to do anything but (a) keep it running somehow, and (b) add more features that got promised to customers in order to land them and that need to be live ASAP.

What's that...? No, I've never experienced that situation myself, why do you ask?

Re: Why products built by large teams fail so often

#20

Post by webmaven »

kpil wrote: post #17
noxToken wrote: post #15

Earlier quoted context omitted.

Non-mobile: https://en.wikipedia.org/wiki/The_Mythical_Man-Month

TMMM contains truly insightful and universally applicable knowledge and insight into building large software systems. It also contains truly insightful knowledge regarding building operative systems at IBM in the seventies. It's one of my favourite books on software development. However, it requires some insight and preexisting knowledge from the reader in order to tell what's what.

> it requires some insight and preexisting knowledge from the reader in order to tell what's what.

The Deadline is a bit more generic (and dramatic): http://tomdemarco.com/Books/deadline.html

Post reply on HN