There’a an architectural lesson to be learned/recalled here for “hardcore” developers.
I didn’t realize that Github ran mostly on Rails until this article and was kind of surprised given the scale of the site and Rails reputation for performance.
It’s a great reminder of architecture/design truism: if your site is not inherently performance bottlenecked, then you problably shouldn’t let language or framework performance be the sole deciding factor in choosing or whether to migrate to a platform. Unless we’re talking about >= order of magnitude difference, or a site whose user experience is being limited by performance. Perf and scalability are just one factor.
Pragmatism across many factors with perf/scale being one, and making yourself as blind as possible to technology religion, biases, personal investments, and digging beyond simplistic conventional wisdom (rails has perf issues), looks to remain a core ability for making arch decisions.
Experience can actually be a
negative: I wouldn’t have a problem developing efficiently in node or coming up with an alternative to migrations for
example.
But what I can or
cannot ramp up on quickly the fastest is likely irrelevant and maybe detrimental when considering what’s best for a project as a whole.
Seeing comments here about productively gains from specific Rails features, and another comment saying they can’t imagine living without migrations as a built in feature, just seem like great reminders of how important it is to try and avoid making decisions relative to the experience or needs of only one or a few people.
It seems like good tech arch decisions need to consider DX issues enough to seem very similar to good UX decisions, the primary contrast being the users have very different stories and requirement scenarios.
I didn’t realize that Github ran mostly on Rails until this article and was kind of surprised given the scale of the site and Rails reputation for performance.
It’s a great reminder of architecture/design truism: if your site is not inherently performance bottlenecked, then you problably shouldn’t let language or framework performance be the sole deciding factor in choosing or whether to migrate to a platform. Unless we’re talking about >= order of magnitude difference, or a site whose user experience is being limited by performance. Perf and scalability are just one factor.
Pragmatism across many factors with perf/scale being one, and making yourself as blind as possible to technology religion, biases, personal investments, and digging beyond simplistic conventional wisdom (rails has perf issues), looks to remain a core ability for making arch decisions.
Experience can actually be a negative: I wouldn’t have a problem developing efficiently in node or coming up with an alternative to migrations for example.
But what I can or cannot ramp up on quickly the fastest is likely irrelevant and maybe detrimental when considering what’s best for a project as a whole.
Seeing comments here about productively gains from specific Rails features, and another comment saying they can’t imagine living without migrations as a built in feature, just seem like great reminders of how important it is to try and avoid making decisions relative to the experience or needs of only one or a few people.
It seems like good tech arch decisions need to consider DX issues enough to seem very similar to good UX decisions, the primary contrast being the users have very different stories and requirement scenarios.