3 ms·

I've also seen small teams of smart engineers using decidedly "boring" stack like Django/Rails + MPA on EBS do as much as much work as a larger teams going hard

by pea 7y ago

I've also seen small teams of smart engineers using decidedly "boring" stack like Django/Rails + MPA on EBS do as much as much work as a larger teams going hard on more cutting edge stuff (React + Redux + Scala on k8s). I wonder what the deciding factor is. I used to be part of a Haskell team and it was actually net negative vs. just using something really batteries included.

xpressvideoz 7y ago
> I used to be part of a Haskell team and it was actually net negative vs. just using something really batteries included. Could you elaborate on that? What were problematic?
BigJono 7y ago
The deciding factor is how complex the code is. You can add a ludicrous amount of complexity into a React app before you've even implemented your first actual feature. People do it all the time. Those people will always get smashed in the marketplace if they have no other advantages and a competitor that's developing PG style with a lean team of actual experts.
nicoburns 7y ago
I feel like the deciding factor might to do with team size, skill, and cohesion as team. Having a smallish team makes it possible (although not easy) to have a team that are all high performers. And that team can easily outperform one 2x-5x as large if not more, because there is a large communication overhead to scaling to more people. If you have competent people who "just get" each other, then communication flows and doesn't actually take up much time. The technology choices follow on from this. If you have a smart team, then you can pick technologies that solve the problem most efficiently, rather than the lowest common denominator that everyone will be able to use, or what's most fashionable (you see this in every field: the "good" people are often following trends or best practices (and doing it well), but the very best tend to have a much more nuanced judgement. They know about the latest thing, they'll use it sometimes, but they keep their own council, and they're not afraid to go off and do something unorthodox if it makes sense for the situation they're in. --- Side point: Incidentally, React is actually on my list of go-to productive boring technologies. It's definitely overused (despite building React apps in my day job, my personal website is built with Hugo, and a lot of sites would be better off with server-rendered Django/Rails/Laravel), but where you need that complex client-side interactivity I think it's the generally best tool for the job.
- abiogenesis 7y ago
  > Having a smallish team makes it possible (although not easy) to have a team that are all high performers. And that team can easily outperform one 2x-5x as large if not more, because there is a large communication overhead to scaling to more people. ^ This. As the project gets larger you can't find enough "star programmers" in a timely manner and have to fall back to mediocracy. Read "The Mythical Man-Month" and the associated Brooks' Law for context.

by pea 7y ago

xpressvideoz 7y ago

> I used to be part of a Haskell team and it was actually net negative vs. just using something really batteries included. Could you elaborate on that? What were problematic?

BigJono 7y ago

The deciding factor is how complex the code is. You can add a ludicrous amount of complexity into a React app before you've even implemented your first actual feature. People do it all the time. Those people will always get smashed in the marketplace if they have no other advantages and a competitor that's developing PG style with a lean team of actual experts.

nicoburns 7y ago

I feel like the deciding factor might to do with team size, skill, and cohesion as team. Having a smallish team makes it possible (although not easy) to have a team that are all high performers. And that team can easily outperform one 2x-5x as large if not more, because there is a large communication overhead to scaling to more people. If you have competent people who "just get" each other, then communication flows and doesn't actually take up much time. The technology choices follow on from this. If you have a smart team, then you can pick technologies that solve the problem most efficiently, rather than the lowest common denominator that everyone will be able to use, or what's most fashionable (you see this in every field: the "good" people are often following trends or best practices (and doing it well), but the very best tend to have a much more nuanced judgement. They know about the latest thing, they'll use it sometimes, but they keep their own council, and they're not afraid to go off and do something unorthodox if it makes sense for the situation they're in. --- Side point: Incidentally, React is actually on my list of go-to productive boring technologies. It's definitely overused (despite building React apps in my day job, my personal website is built with Hugo, and a lot of sites would be better off with server-rendered Django/Rails/Laravel), but where you need that complex client-side interactivity I think it's the generally best tool for the job.

abiogenesis 7y ago
> Having a smallish team makes it possible (although not easy) to have a team that are all high performers. And that team can easily outperform one 2x-5x as large if not more, because there is a large communication overhead to scaling to more people. ^ This. As the project gets larger you can't find enough "star programmers" in a timely manner and have to fall back to mediocracy. Read "The Mythical Man-Month" and the associated Brooks' Law for context.