4 ms·

I like the post but it does somewhat miss the point of these comments when they’re made. It’s not usually someone saying they could rebuild the whole site / pro

I like the post but it does somewhat miss the point of these comments when they’re made. It’s not usually someone saying they could rebuild the whole site / product / company in a weekend but rather challenging the value that everything beyond MVP is adding and all the staff that go into supporting everything beyond MVP. Companies tend to vastly over-complicate things and to support that end up having ever growing teams to support the ever growing over-complexity and feature bloat. I can’t tell you the number of times a team has said it takes so long to deliver something with 3x the number of engineers because they need more testing, backend and such but meanwhile the core product features that customers care about are delayed and not materializing. It’s not that these other things don’t matter but all the “other stuff” shouldn’t take priority over having a lean and mean product that works and people use. Thus it’s less “why does this company have 100 engineers” and more “why does this company not just exist as a far simpler and leaner product?”

paxys 6y ago
Simply because there is demand for that "other stuff" that you are writing off. Every user and organization has their own workflows and are looking for different things when they spend money on a piece of software. What you consider a core feature others may not use at all.
- code4tee 6y ago
  What you describe is often part of the problem. Companies are often far to quick to chase after every feature request and endlessly customize product for each customer. Finding the balance between meeting true feature needs and ending up with a mess designed by committee is the ultimate art in product development.
cmckn 6y ago
> It’s not that these other things don’t matter but all the “other stuff” shouldn’t take priority... Totally agree with you; I think the sentiment behind "I could do that in a weekend" is that shipping the core functionality can be done quickly, and iterating on the "other things" can be done after launch in many cases. Not everything has to be as robust as possible on day one. Google didn't have BigTable, MapReduce, and Borg the day the search bar went live. Shipping features is my favorite part of the job, it'd be great to have those wins as often as possible and cross other bridges when we come to them.
ineedasername 6y ago
>“why does this company not just exist as a far simpler and leaner product?” I'm sure there are bloated teams, but apart from those the argument against a very lean product is growth of the consumer base. You make a lean product, get some users. They love it. You do a little research into customer churn though, or followup on marketing efforts to people that didn't yield, and find out that feature X is a common thread: you don't have feature X. So you build feature X. You gain incremental customer & revenue growth as a result. Then the process begins again. The problem is that at some point you reach a point of diminishing returns, and if you don't recognize that point, you'll still go over the bloat line.
yibg 6y ago
A lot of it depends on scale. At facebook's scale (user base and revenue), it's worth paying 10 engineers to make little tweaks in a narrow area of the product because that little polish, while not worth doing for a smaller company, may bring in an additional 10s or 100s of millions in revenue. Similarly for tooling. Most shops can and should use stuff off the shelf. But when you have thousands or 10s of thousands of engineers, making all of their lives even a little bit easier is worth putting together a team.

paxys 6y ago

Simply because there is demand for that "other stuff" that you are writing off. Every user and organization has their own workflows and are looking for different things when they spend money on a piece of software. What you consider a core feature others may not use at all.

code4tee 6y ago
What you describe is often part of the problem. Companies are often far to quick to chase after every feature request and endlessly customize product for each customer. Finding the balance between meeting true feature needs and ending up with a mess designed by committee is the ultimate art in product development.

cmckn 6y ago

> It’s not that these other things don’t matter but all the “other stuff” shouldn’t take priority... Totally agree with you; I think the sentiment behind "I could do that in a weekend" is that shipping the core functionality can be done quickly, and iterating on the "other things" can be done after launch in many cases. Not everything has to be as robust as possible on day one. Google didn't have BigTable, MapReduce, and Borg the day the search bar went live. Shipping features is my favorite part of the job, it'd be great to have those wins as often as possible and cross other bridges when we come to them.

ineedasername 6y ago

>“why does this company not just exist as a far simpler and leaner product?” I'm sure there are bloated teams, but apart from those the argument against a very lean product is growth of the consumer base. You make a lean product, get some users. They love it. You do a little research into customer churn though, or followup on marketing efforts to people that didn't yield, and find out that feature X is a common thread: you don't have feature X. So you build feature X. You gain incremental customer & revenue growth as a result. Then the process begins again. The problem is that at some point you reach a point of diminishing returns, and if you don't recognize that point, you'll still go over the bloat line.

yibg 6y ago

A lot of it depends on scale. At facebook's scale (user base and revenue), it's worth paying 10 engineers to make little tweaks in a narrow area of the product because that little polish, while not worth doing for a smaller company, may bring in an additional 10s or 100s of millions in revenue. Similarly for tooling. Most shops can and should use stuff off the shelf. But when you have thousands or 10s of thousands of engineers, making all of their lives even a little bit easier is worth putting together a team.