4 ms·

Part of the problem is that software engineering time is more expensive than just buying better hardware or letting the end user deal with the slow software. S

by txdv 6y ago

Part of the problem is that software engineering time is more expensive than just buying better hardware or letting the end user deal with the slow software. So business just buy better available hardware rather than spending time optimizing and end user want usually the cheapest product. There are only a few organizations like Sublime HQ who focus on fast software. But they are producing niche products, catering to other software developers who appreciate the fast nature of their software and have the money to spend on it. I personally bought Sublime Merge and my IT friends who make a lot of money are perplexed by my decision spending 100 on an amazing development tool. I also sometimes dream with my programming buddy about creating a company which creates fast software like Sublime HQ, but it is really hard to sell this kind of software.

est31 6y ago
It depends on the number of users. If say Slack got 10% faster, it'd deliver tremendous productivity increases for customers all around the world. So in theory, there is a large incentive here, and Slack can absolutely capture a part of the value they'd be creating from doing such a speedup. But Slack is a product with many users. Speeding up highly specialized products that have maybe 100 users doesn't create as much value.
- txdv 6y ago
  If you reach Facebook scale and optimize a flow by 10%, you can basically save thousands of dollars per month making optimizations valuable for the company again. This is one of the aspects where optimizations starts making sense again.
  - tonyedgecombe 6y ago
    The trouble with Facebook is the obvious optimisation for them is to offload work from their servers to my device. Hence we get bloated clients.
    - txdv 6y ago
      Of course, they will seek to optimize the software they run on their own servers :)
averros 6y ago
Not necessarily. I recently earned 9-figure comp as an individual contributor by using my old-school skills for writing performance and correctness-critical software (and it's rather complex, too).
Cthulhu_ 6y ago
In theory yes, but at the same time, are we as software developers really more time-efficient as we used to be? I mean I'm still writing CRUD software ten years later; the tools have changed from idk, jquery mobile and php to React and go, but I don't feel any faster doing it. I want to say that things like form validation are faster and easier now, but no, they've just been reinvented a few times with changing underlying technology. I want to say that they solved the ORM problem, but nope, still crap, and again because of having to re-invent the wheel for a new language, environment, and generation of developers. Did the existing tools and languages improve much? Also no, at least not that I know of, still wouldn't use Hibernate if I can help it. So in many ways things feel like they have advanced, but at least speaking for myself, at the same time things feel like they are still the same. At least for the moment my Go application recompiles / restarts much faster than the old Java / Spring applications I used to work with. Which puts it on par with the PHP experience from before that.
- keyle 6y ago
  This is a very good point. In many ways I feel we're optimizing complexity without solving any old problems. We invent new problems to solve, and we do solve them, but still are left with the same old problems.
- ksec 6y ago
  Which basically sums up what Alan Kay describe as Reinventing the Flat Tires. And it felt especially true in the field of Web Technologies. >at the same time things feel like they are still the same. In the past few years I have always felt things are far too complex. We just didn't make anything simpler.
- deergomoo 6y ago
  > I want to say that things like form validation are faster and easier now, but no I’d actually say forms are more of a pain in an SPA than they are with server rendering. You have to track the state of every field so input doesn’t get clobbered on a re-render, which isn’t difficult but can be pretty tedious, especially if it’s a very dynamic form. And if you want native input attributes like `required` to work you need to still do a native form submission, but then intercept it and do your AJAX request or whatever instead. The only part that’s really easier is handling server-side validation errors, because instead of trying to re-construct the populated form using the submitted input, you can just leave it all on screen.
deleted 6y ago
[deleted]
solarkraft 6y ago
> but it is really hard to sell this kind of software. It's hard to sell software just on speed, but it is an integral part of good UX (that feeling of a good, light weight, robust piece of software that is there to help instead of hinder). I for one desire that a lot and I think many others do too (see the success of Apple).

by txdv 6y ago

est31 6y ago

It depends on the number of users. If say Slack got 10% faster, it'd deliver tremendous productivity increases for customers all around the world. So in theory, there is a large incentive here, and Slack can absolutely capture a part of the value they'd be creating from doing such a speedup. But Slack is a product with many users. Speeding up highly specialized products that have maybe 100 users doesn't create as much value.

txdv 6y ago
If you reach Facebook scale and optimize a flow by 10%, you can basically save thousands of dollars per month making optimizations valuable for the company again. This is one of the aspects where optimizations starts making sense again.
- tonyedgecombe 6y ago
  The trouble with Facebook is the obvious optimisation for them is to offload work from their servers to my device. Hence we get bloated clients.
  - txdv 6y ago
    Of course, they will seek to optimize the software they run on their own servers :)

averros 6y ago

Not necessarily. I recently earned 9-figure comp as an individual contributor by using my old-school skills for writing performance and correctness-critical software (and it's rather complex, too).

Cthulhu_ 6y ago

In theory yes, but at the same time, are we as software developers really more time-efficient as we used to be? I mean I'm still writing CRUD software ten years later; the tools have changed from idk, jquery mobile and php to React and go, but I don't feel any faster doing it. I want to say that things like form validation are faster and easier now, but no, they've just been reinvented a few times with changing underlying technology. I want to say that they solved the ORM problem, but nope, still crap, and again because of having to re-invent the wheel for a new language, environment, and generation of developers. Did the existing tools and languages improve much? Also no, at least not that I know of, still wouldn't use Hibernate if I can help it. So in many ways things feel like they have advanced, but at least speaking for myself, at the same time things feel like they are still the same. At least for the moment my Go application recompiles / restarts much faster than the old Java / Spring applications I used to work with. Which puts it on par with the PHP experience from before that.

keyle 6y ago
This is a very good point. In many ways I feel we're optimizing complexity without solving any old problems. We invent new problems to solve, and we do solve them, but still are left with the same old problems.
ksec 6y ago
Which basically sums up what Alan Kay describe as Reinventing the Flat Tires. And it felt especially true in the field of Web Technologies. >at the same time things feel like they are still the same. In the past few years I have always felt things are far too complex. We just didn't make anything simpler.
deergomoo 6y ago
> I want to say that things like form validation are faster and easier now, but no I’d actually say forms are more of a pain in an SPA than they are with server rendering. You have to track the state of every field so input doesn’t get clobbered on a re-render, which isn’t difficult but can be pretty tedious, especially if it’s a very dynamic form. And if you want native input attributes like `required` to work you need to still do a native form submission, but then intercept it and do your AJAX request or whatever instead. The only part that’s really easier is handling server-side validation errors, because instead of trying to re-construct the populated form using the submitted input, you can just leave it all on screen.

deleted 6y ago

[deleted]

solarkraft 6y ago

> but it is really hard to sell this kind of software. It's hard to sell software just on speed, but it is an integral part of good UX (that feeling of a good, light weight, robust piece of software that is there to help instead of hinder). I for one desire that a lot and I think many others do too (see the success of Apple).