15 ms·

The push for the need of scaling out started with Ruby and Python's lack of performance. The reason being pushed at the time was, "developer time was more expe

by ww520 7y ago

The push for the need of scaling out started with Ruby and Python's lack of performance. The reason being pushed at the time was, "developer time was more expensive than hardware." Well, that didn't count the amortization of developer time over the lifetime of the product once the product was developed.

Silhouette 7y ago
If hardware speeds and capacities had continued to increase as rapidly as they used to, there might have been some truth in that. Buying a computer with a faster CPU or a bigger disk or more RAM was a relatively cheap solution to a lot of performance problems for a long time, in no small part because it typically required zero changes to the software itself. However, once you're talking about qualitatively different hardware architecture (scaling out instead of up) and therefore also qualitatively different software architecture, it's far from obvious that the premise still holds or that we should even expect it to.
shrimpx 7y ago
It's mostly a fallacy that a demanded product becomes "developed". Maybe a game that gains cult status and therefore a long tail end of life. But popular web services are in constant churn and in that space it's valid to trade hardware for programmer productivity.
- ww520 7y ago
  Backend web development doesn't change much once developed. How many ways can one do CRUD on the backend?
  - filleduchaos 7y ago
    Out of curiosity, have you ever actually been employed as a backend web developer?
    - ww520 7y ago
      Not specifically just backend but full stack projects that included backend.
  - filleokus 7y ago
    In my experience this is only true iff the system never gets any more user facing features. Every new non-insignificant feature requires a new REST-API route, or database table or modification of the GraphQL schema. And depending on how you designed the backend, even small redesigns of the frontend might require changes on the backend. Consider a simple app showing car rentals, where you initially have something like /car/[id], then the frontend guys realise that we need to show cars rented by each customer and it's necessary to have /customer/[id]/rentals. (Of course it's possible to design a system without any schemas or normalisations, which would make your statement truer, but that's rarely attractive for other reasons.)
    - ww520 7y ago
      But all those are just extensions using the established frameworks and development practices for that backend application. Once those are developed, it’s pretty easy to add new features. I would argue using Ruby and Python like script languages brings no significant benefit in development time. In fact they make it worse when working on an existing app, with the extra unit tests, difficulty in refactoring, and extra performance work.
  - drinfinity 7y ago
    Try it. It might surprise you.
golergka 7y ago
> Well, that didn't count the amortization of developer time over the lifetime of the product once the product was developed. I'll bite. I think it actually counts not only that, but also the probability that the product will actually get to be developed, and not need to significantly pivot, therefore throwing all developer time spent on perfomance to garbage.

by ww520 7y ago

Silhouette 7y ago

If hardware speeds and capacities had continued to increase as rapidly as they used to, there might have been some truth in that. Buying a computer with a faster CPU or a bigger disk or more RAM was a relatively cheap solution to a lot of performance problems for a long time, in no small part because it typically required zero changes to the software itself. However, once you're talking about qualitatively different hardware architecture (scaling out instead of up) and therefore also qualitatively different software architecture, it's far from obvious that the premise still holds or that we should even expect it to.

shrimpx 7y ago

It's mostly a fallacy that a demanded product becomes "developed". Maybe a game that gains cult status and therefore a long tail end of life. But popular web services are in constant churn and in that space it's valid to trade hardware for programmer productivity.

ww520 7y ago
Backend web development doesn't change much once developed. How many ways can one do CRUD on the backend?
- filleduchaos 7y ago
  Out of curiosity, have you ever actually been employed as a backend web developer?
  - ww520 7y ago
    Not specifically just backend but full stack projects that included backend.
- filleokus 7y ago
  In my experience this is only true iff the system never gets any more user facing features. Every new non-insignificant feature requires a new REST-API route, or database table or modification of the GraphQL schema. And depending on how you designed the backend, even small redesigns of the frontend might require changes on the backend. Consider a simple app showing car rentals, where you initially have something like /car/[id], then the frontend guys realise that we need to show cars rented by each customer and it's necessary to have /customer/[id]/rentals. (Of course it's possible to design a system without any schemas or normalisations, which would make your statement truer, but that's rarely attractive for other reasons.)
  - ww520 7y ago
    But all those are just extensions using the established frameworks and development practices for that backend application. Once those are developed, it’s pretty easy to add new features. I would argue using Ruby and Python like script languages brings no significant benefit in development time. In fact they make it worse when working on an existing app, with the extra unit tests, difficulty in refactoring, and extra performance work.
- drinfinity 7y ago
  Try it. It might surprise you.

golergka 7y ago

> Well, that didn't count the amortization of developer time over the lifetime of the product once the product was developed. I'll bite. I think it actually counts not only that, but also the probability that the product will actually get to be developed, and not need to significantly pivot, therefore throwing all developer time spent on perfomance to garbage.