3 ms·

> tech stacks are important I'd argue that tech stacks are unimportant 99% of the time. It really doesn't matter if you use Java or PHP or Python or Node. Fai

by gav 6y ago

> tech stacks are important I'd argue that tech stacks are unimportant 99% of the time. It really doesn't matter if you use Java or PHP or Python or Node. Failures that I have seen due to the choice of tech stack include: - Technologies that your team doesn't know well - Technologies where hiring is difficult (I've seen attempts to turn C# devs into F# devs and Java devs into Clojure devs and productivity suffered) - Choosing the flavor of the week, whether that's the hottest Javascript framework or newest NoSQL database - Over-architecting thinking you were Google-scale with the added complexity hurting velocity (it doesn't matter if you can scale to millions of users if you can't get there) Generally boring tech stacks work. By the time your Ruby/MySQL monolith has performance issues, hopefully you're successful enough that you can scale out the worst performing parts in some other language/datastore combination. You'll be in a better position to fix performance problems are when you have them rather then when you are trying to predict them up front.

throwaway894345 6y ago
> I'd argue that tech stacks are unimportant 99% of the time. I think this is true if your product is so wildly profitable that differences in tech stack are relatively unimportant--use whatever lets you move the fastest and just solve performance problems by scaling vertically or horizontally. If your business is cost-sensitive and your cloud-bill is a significant portion of your expense, then tech stack starts to matter a lot. Further, your tech stack doesn't matter very much when you're just writing a CRUD webapp--you can use whichever stack and you won't run into issues unless you're massively successful; however, if your app involves a lot of data crunching per request, the stack and architecture matter a lot more (you might have to do more than naive vertical scaling to meet performance requirements). Note that I'm a big proponent of "boring", but "boring stacks work" is orthogonal to "tech stacks don't matter [much]". Maybe these cases are really only 1% of cases, I'm not sure--there are a lot of CRUD webapps out there, so maybe this is true. But it's not much of a consolation when your use case is one of those 1%.
- gav 6y ago
  If your app involves a lot of data crunching and that crunching is the bottleneck, then it makes sense to optimize that part. It's better to have something slow and correct to optimize, so writing it first time round in a slower language isn't a bad thing. Secondly, shunting work out of your app is easier now than it's ever been. Enqueue and process in a serverless way. Then you can write whatever code that makes most sense for that problem.
  - throwaway894345 6y ago
    > It's better to have something slow and correct to optimize, so writing it first time round in a slower language isn't a bad thing. It's better to have something that's fast and correct the first time. Rewrites are typically prohibitively expensive, and we're not getting anything from using a slow language (negligible productivity gains vs Go, for example). Moreover, there isn't much room to optimize with Python for many applications--you can't always subprocess or rewrite in C because the de/serialization costs will eat any savings from parallelism or C. Not to mention increased complexity.
    - dragonwriter 6y ago
      > Rewrites are typically prohibitively expensive, Big bang rewrites are (and, moreover, tend to lose correctness from the source), Ship of Theseus ones are not and do not have that tendency. If you can do component-wise replacement, then fast-to-develop and correct but suboptimal performance is a better deal than anything which trades off either of the others for performance.
      - throwaway894345 6y ago
        It's feasible, but it's still very costly. And again, there's no reason to pick a language that is going to force you to do a rewrite (incremental or not) when there are languages that offer good performance and good iteration velocity.
        mercer 6y ago
trimbo 6y ago
You successfully argued that tech stacks are important, just not primarily for technical reasons.

by gav 6y ago

throwaway894345 6y ago

> I'd argue that tech stacks are unimportant 99% of the time. I think this is true if your product is so wildly profitable that differences in tech stack are relatively unimportant--use whatever lets you move the fastest and just solve performance problems by scaling vertically or horizontally. If your business is cost-sensitive and your cloud-bill is a significant portion of your expense, then tech stack starts to matter a lot. Further, your tech stack doesn't matter very much when you're just writing a CRUD webapp--you can use whichever stack and you won't run into issues unless you're massively successful; however, if your app involves a lot of data crunching per request, the stack and architecture matter a lot more (you might have to do more than naive vertical scaling to meet performance requirements). Note that I'm a big proponent of "boring", but "boring stacks work" is orthogonal to "tech stacks don't matter [much]". Maybe these cases are really only 1% of cases, I'm not sure--there are a lot of CRUD webapps out there, so maybe this is true. But it's not much of a consolation when your use case is one of those 1%.

gav 6y ago
If your app involves a lot of data crunching and that crunching is the bottleneck, then it makes sense to optimize that part. It's better to have something slow and correct to optimize, so writing it first time round in a slower language isn't a bad thing. Secondly, shunting work out of your app is easier now than it's ever been. Enqueue and process in a serverless way. Then you can write whatever code that makes most sense for that problem.
- throwaway894345 6y ago
  > It's better to have something slow and correct to optimize, so writing it first time round in a slower language isn't a bad thing. It's better to have something that's fast and correct the first time. Rewrites are typically prohibitively expensive, and we're not getting anything from using a slow language (negligible productivity gains vs Go, for example). Moreover, there isn't much room to optimize with Python for many applications--you can't always subprocess or rewrite in C because the de/serialization costs will eat any savings from parallelism or C. Not to mention increased complexity.
  - dragonwriter 6y ago
    > Rewrites are typically prohibitively expensive, Big bang rewrites are (and, moreover, tend to lose correctness from the source), Ship of Theseus ones are not and do not have that tendency. If you can do component-wise replacement, then fast-to-develop and correct but suboptimal performance is a better deal than anything which trades off either of the others for performance.
    - throwaway894345 6y ago
      It's feasible, but it's still very costly. And again, there's no reason to pick a language that is going to force you to do a rewrite (incremental or not) when there are languages that offer good performance and good iteration velocity.
      - mercer 6y ago

trimbo 6y ago

You successfully argued that tech stacks are important, just not primarily for technical reasons.