Live data from Hacker News

Why products built by large teams fail so often

blog.mojotech.com

41–43 of 43 posts

Re: Why products built by large teams fail so often

#41
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…

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.

Re: Why products built by large teams fail so often

#42
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…

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.

Known as Gall's law. From Wikipedia:

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

#43
post #18

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 o…

Most developers in small teams fall into one or more of the traps of freedom that hurts technically and makes their lives tougher than necessary. With enterprise start-ups you need to be just as agile and fleet-footed as all the b2c start-ups when it comes to backends to survive. Depending upon how much overlap of features across customers your sales pipeline is bringing in, you may share only 10% of code between different customers (basically glorified outsourced software development while pretending to be a product company) and you will need to architect your infrastructure with it too. Getting a feel for where debt exists, fixing it when appropriate, and going at start-up speeds without getting too sloppy is a challenge most b2c developers are familiar with. Hockey stick growth exists as a huge spike as a single customer gets signed, and now you need to scale your software 100x past what you tested within weeks while oftentimes not being able to use modern tools like cloud infrastructure services because your customers forbid it legally. Now add in much tougher (and worse - specific) infrastructure and security requirements across the board and it's no wonder b2b software tends to suck.

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.

Post reply on HN