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…
Why products built by large teams fail so often
41–43 of 43 posts
Re: Why products built by large teams fail so often
#42Generally 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…
I am reminded by something I read by a person who studies complex systems. He said that every complex system that works well started with a simple system that worked well, and then gradually added new features over time.
Gall's Law is a rule of thumb for systems design from Gall's book Systemantics: How Systems Really Work and How They Fail. It states:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. – John Gall
https://en.wikipedia.org/wiki/John_Gall_(author)#Gall.27s_la...
Re: Why products built by large teams fail so often
#43in 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 o…
Hiring developers early on with prior experience in the business domain is critical for company success for this reason. Every developer knows how developers work, so tools by developers for developers tend to work fairly often. Most developers probably don't know anything about how your customers work though and will have difficulty prioritizing what's the most fluid parts and what's not regardless of how brilliant and fast they may be.
It's tough to tell whether haphazard selling or haphazard technical design has a bigger impact upon codebases. Add in realities like team turnover and even technical design may matter little compared to how well a codebase is documented for the health of the codebase. I can stare at thousands of unit tests but without some history and organizational know-how it's likely for a successor to repeat the same mistakes by trying to mimic existing patterns.