4 ms·

There's always a comment here on HN wondering why company X has so many engineers for such a seemingly simple product. The answer is, unsurprisingly, not that

by eloff 6y ago

There's always a comment here on HN wondering why company X has so many engineers for such a seemingly simple product. The answer is, unsurprisingly, not that they're terribly inefficient. Rather it's that running a popular service at scale is hard, the long tail of features is really a long tail, and a lot of effort goes into even simple things because small differences really add up when multiplied by large N.

grensley 6y ago
There's always a mix between "now we're at scale and need to solve this really hard data sync problem" and "let's build an internal slack clone because we can".
- eloff 6y ago
  Ouch, data sync his close to home for me. That was my first job. Not an easy problem at all. Tip for those of you with the same problem, if you can, try to sync both the data and the actions taken to produce the data (event sourcing) and try to eliminate sources of indeterminism.
  - swyx 6y ago
    why both? isn't that wasteful? which one wins if they disagree? do you sync both at the same frequency?
    - eloff 6y ago
      It depends on the business logic. If e.g. a user updates a numeric value on an entity, and there's a conflict probably you choose the most recent value. The action taken (user updates value) is pretty useless in this case. In other cases, e.g. inventory reduced by X because X units purchased/consumed - then it's more important to have the action itself, and a conflict would involve applying both actions and possibly alerting someone if that causes the value to be invalid (e.g. inventory below 0.)
vmception 6y ago
and a team told their manager they needed to redo all the unit tests in order to stay relevant
plorkyeran 6y ago
Except for the part where even if you ignore the sales and marketing expenses they're barely breaking even. They're failing to make software for less than they can sell it for, and perhaps some of those hard problems which took 50 engineers to solve would have been better to have gone unsolved even if they lost some sales as a result.
- chrisco255 6y ago
  That's normal in a SaaS. They gear everything towards growth in revenue, not necessarily profit, since it's much easier to keep existing SaaS customers (most good SaaS have 95+% retention) than to earn new ones, and at a certain point you've got a flywheel going so that you can perhaps reduce headcount increases or stay flat while your revenue continues to grow, and then you coast into profitability from there.
smabie 6y ago
I mean, I think the real answer is that most companies use inexpressive languages with heavy emphasis on mutation.
yashap 6y ago
This is a big part of it, but I wouldn’t downplay the inefficiency too much. A pattern I’ve personally seen: * Small team of 5 devs and maybe 1 manager working on some large area of the product is very efficient * Startup is growing users/revenue very fast, attracts big VC investment * Major hiring, a year or two later that same area of the product has 30 devs, 5 product managers, 5 dev managers, 3 designers, a manager of the dev managers, a manager of the product managers/designers, and a manager of the dev and product managers * There’s too many cooks in the kitchen, nobody feels empowered to make decisions, meetings multiply like crazy, every decision takes exponentially longer to make than before * Instead of planning 1 sprint ahead, you start doing quarterly plans, 3 year visions, customer facing roadmaps, etc. “Predictability” becomes more important than productivity * Teams know that only predictability matters, so they start making really conservative estimates, just to be safe * If you have 2 months to do 1 month of work ... it’ll take 2 months. And this starts becoming the new norm * Plus, you start spending more and more time planning, “scoping out epics”, etc., to get “better” estimates You get the idea - pretty soon that 45 person team ships not much more than the 6 person team used to. Nobody is purposefully dogging it, or trying to go slow, but it happens when companies grow unless you’re really, REALLY good at fighting it. And few companies are. Everyone is BUSY, but they’re busy doing quarterly plans, “full potential analyses”, change management, meeting with stakeholders, working on all sorts of checkboxes to get all sorts of security certifications to sell to one or two big government buyers, working on “business development” projects that users don’t care about, etc.
- quickthrower2 6y ago
  I would argue that some of that baggage doesn't make you less efficient. I mean it makes you less efficient at the features per hour metric, but what about the business value metric? If you have meetings to really think things through and plan, maybe whole areas of sterile development work are avoided and that is valuable. Remember there are businesses that do well writing no code at all! Code or features isn't what it is al about, but in a tech company it is somewhere between nothing and everything.
  - yashap 6y ago

by eloff 6y ago

grensley 6y ago

There's always a mix between "now we're at scale and need to solve this really hard data sync problem" and "let's build an internal slack clone because we can".

eloff 6y ago
Ouch, data sync his close to home for me. That was my first job. Not an easy problem at all. Tip for those of you with the same problem, if you can, try to sync both the data and the actions taken to produce the data (event sourcing) and try to eliminate sources of indeterminism.
- swyx 6y ago
  why both? isn't that wasteful? which one wins if they disagree? do you sync both at the same frequency?
  - eloff 6y ago
    It depends on the business logic. If e.g. a user updates a numeric value on an entity, and there's a conflict probably you choose the most recent value. The action taken (user updates value) is pretty useless in this case. In other cases, e.g. inventory reduced by X because X units purchased/consumed - then it's more important to have the action itself, and a conflict would involve applying both actions and possibly alerting someone if that causes the value to be invalid (e.g. inventory below 0.)

vmception 6y ago

and a team told their manager they needed to redo all the unit tests in order to stay relevant

plorkyeran 6y ago

Except for the part where even if you ignore the sales and marketing expenses they're barely breaking even. They're failing to make software for less than they can sell it for, and perhaps some of those hard problems which took 50 engineers to solve would have been better to have gone unsolved even if they lost some sales as a result.

chrisco255 6y ago
That's normal in a SaaS. They gear everything towards growth in revenue, not necessarily profit, since it's much easier to keep existing SaaS customers (most good SaaS have 95+% retention) than to earn new ones, and at a certain point you've got a flywheel going so that you can perhaps reduce headcount increases or stay flat while your revenue continues to grow, and then you coast into profitability from there.

smabie 6y ago

I mean, I think the real answer is that most companies use inexpressive languages with heavy emphasis on mutation.

yashap 6y ago

This is a big part of it, but I wouldn’t downplay the inefficiency too much. A pattern I’ve personally seen: * Small team of 5 devs and maybe 1 manager working on some large area of the product is very efficient * Startup is growing users/revenue very fast, attracts big VC investment * Major hiring, a year or two later that same area of the product has 30 devs, 5 product managers, 5 dev managers, 3 designers, a manager of the dev managers, a manager of the product managers/designers, and a manager of the dev and product managers * There’s too many cooks in the kitchen, nobody feels empowered to make decisions, meetings multiply like crazy, every decision takes exponentially longer to make than before * Instead of planning 1 sprint ahead, you start doing quarterly plans, 3 year visions, customer facing roadmaps, etc. “Predictability” becomes more important than productivity * Teams know that only predictability matters, so they start making really conservative estimates, just to be safe * If you have 2 months to do 1 month of work ... it’ll take 2 months. And this starts becoming the new norm * Plus, you start spending more and more time planning, “scoping out epics”, etc., to get “better” estimates You get the idea - pretty soon that 45 person team ships not much more than the 6 person team used to. Nobody is purposefully dogging it, or trying to go slow, but it happens when companies grow unless you’re really, REALLY good at fighting it. And few companies are. Everyone is BUSY, but they’re busy doing quarterly plans, “full potential analyses”, change management, meeting with stakeholders, working on all sorts of checkboxes to get all sorts of security certifications to sell to one or two big government buyers, working on “business development” projects that users don’t care about, etc.

quickthrower2 6y ago
I would argue that some of that baggage doesn't make you less efficient. I mean it makes you less efficient at the features per hour metric, but what about the business value metric? If you have meetings to really think things through and plan, maybe whole areas of sterile development work are avoided and that is valuable. Remember there are businesses that do well writing no code at all! Code or features isn't what it is al about, but in a tech company it is somewhere between nothing and everything.
- yashap 6y ago