7 ms·

I get the frustration, but I think this is just the cost of the incredible volume of software that we have. As software engineers we pride ourselves on our

I get the frustration, but I think this is just the cost of the incredible volume of software that we have. As software engineers we pride ourselves on our systemic thinking, so it's tempting to look at the situation and say "we can and should do better". But it's an illusion to think of software ecosystems as being designed. The reality is individuals, teams and even huge companies are constrained by ecosystems which are too big to really control and optimize in a systemic fashion. Useful software today beats perfect software tomorrow. That's why software is not well-optimized: because less optimized software beat it to market at multiple layers of the stack. That's why web apps slowly killed native apps: because shipping binaries to multiple platforms is way harder than loading a URL in a browser (or thin wrapper thereof). One thing I've learned the hard way in life is to focus on what one can control. We may not like the tradeoffs others have made and the systemic outcomes they led to, but we can't control them. A better tactic is to pick one very specific area you think you can make a dent and focus on that.

routerl 4y ago
> A better tactic is to pick one very specific area you think you can make a dent and focus on that. Amen. Best practices taught me "don't break extra windows, and repair broken ones as you find them", but I'm finally at a point in my career where I can say, with confidence, that some broken windows aren't worth fixing; you might have enough expertise to know that it should be fixed, while simultaneously lacking the expertise to do so in a cost-effective way. Case in point: in the iOS app I'm currently working on for a client, my team discovered a bug that was, very clearly, an interest payment on the technical debt the client has been accruing. The "correct" bug fix would entail rewriting a lot of existing functionality (i.e. paying down a big chunk of the principal, on the technical debt). This was not cost effective for us, since we were being paid to fix the bug as written. So we fixed the bug, while introducing functionality that could, in the future, be used to pay down the tech debt principal, should the client desire to do so. Spoilers: the client will never desire to do so, and therefore we've actually just added cruft to the codebase. But this conclusion is not allowed, in the client-provider relationship; the bug is fixed, therefore contract conditions have been met, therefore the work is done. The cause of bad software is, simply, that the incentive structures and scheduling required for making good software don't usually exist.
- mikepurvis 4y ago
  > the bug is fixed, therefore contract conditions have been met, therefore the work is done Agile-type workflows also push toward this kind of prioritization— focus on story points, requested features, value delivered to the "customer", etc etc. It's obviously important, especially if the task at hand is to rein in a team consumed with grand rewrites and architecture astronaut stuff. But at a certain point, the pendulum has swung too far the other way, and you do need competent technical oversight— not just someone who assigns you a sprint or two to "pay down debt", but who engages meaningfully in understanding what the debt is, how it came about, and what the ongoing cost is of carrying it; and who can actually set milestones on the cleanup effort and communicate to the larger organization how it was valuable work to have done.
  - andrekandre 4y ago
    > But at a certain point, the pendulum has swung too far the other way, and you do need competent technical oversight— not just someone who assigns you a sprint or two to "pay down debt" yep, if you are truly agile, you will be continuously improving the whole system you are working on otherwise it gets harder and slower to "deliver stories" to your customers... its a balance to be sure.
    - mikepurvis 4y ago
      Oh definitely, but that requires everyone to be on the same page about that, that every feature has a built in overhead of whatever% time allotted to general maintenance. Otherwise it's just a prisoner's dilemma where the one guy who doesn't do any of that work will be at the top of the list for promotion because he gets 30% more done than anyone else, as measured in story points.
      - andrekandre 4y ago
        > prisoner's dilemma where the one guy who doesn't do any of that work will be at the top of the list for promotion because he gets 30% more done i see this so often its not even funny anymore... (insert crying face here)
christophilus 4y ago
> That's why web apps slowly killed native apps I prefer web apps over native for most things. I only trust a handful of native applications on my computer (neovim, Postgres, compiler tooling, stock Linux utilities, etc) Corporate applications are highly suspect to me. I’m not sure why. I much prefer running things in a sandbox like the browser. I also find that my resource usage is lower when I run Zoom, Slack, Reddit, etc in a browser vs their resource-hungry native applications.
walleeee 4y ago
> Useful software today beats perfect software tomorrow. this isn't a natural law, it's a product of social incentives and amenable (if perhaps difficult) to change > A better tactic is to pick one very specific area you think you can make a dent and focus on that. good advice!
- BirAdam 4y ago
  Useful today is a matter of time preference, and as all software is now essentially free, the cost is computer time you already have available. It may not be a law like a law of physics, but it is an observed law of behavior.
tepitoperrito 4y ago
I dunno, I'm gonna try writing a pattern language to avoid getting tied up with one specific area. Friends can fill in the blanks. https://en.m.wikipedia.org/wiki/A_Pattern_Language https://en.m.wikipedia.org/wiki/A_Pattern_Language
_gabe_ 4y ago
> but I think this is just the cost of the incredible volume of software that we have. But it's not. The author gives specific modern examples of individual people absolutely destroying our concepts of how fast an app should be: >> Work Martin Thompson has being doing (LMAX Disruptor, SBE, Aeron) is impressive, refreshingly simple and efficient. Xi editor by Raph Levien seems to be built with the right principles in mind. Jonathan Blow has a language he alone develops for his game that can compile 500k lines per second on his laptop. That’s cold compile, no intermediate caching, no incremental builds. Jonathan Blow's language compiles 500K lines of code in 1 second! It takes me 20 minutes to do a full build of our monorepo, which is nowhere near 500K lines of code. And it's not even compiling and optimizing and linking, it's just transpiling typescript to javascript. It's ridiculous. It's ridiculous to think we can't do better. Another case in point, modern games can render millions of polygons now (with UE5) at 60fps. And a modern web browser can hardly render some of these static web pages on my PC with an RTX 2080 and 48GB of RAM at 60FPS. Something is seriously wrong with our ideas of "performant code" if we think this is acceptable.
- kvark 4y ago
  I worked on both games and browsers, and I’ve seen this comparison being made before. Browsers are way more complex than what meets the eye. There are requirements for high quality text, page consistency, lots of different content types, fine 2D graphics, network ops, and multiply low power consumption requirements on top. WebRender is somewhat a game engine. Real games are happy to cut all these corners, for the sake of bring impressive, and they mostly rely on hardware-accelerated functions.
  - thethirdone 4y ago
    I think web browsers could get framerates on typical webpages to 180 fps if it were a priority. I have found some sites that should be renderable at super high framerates that struggled to keep an average of 60 fps. One reason that browsers aren't super fast is that it will always be possible to make a super slow site. Speeding up sites like HN is really not very important to battery life or user experience. Also the necessary complexities of the browser make it much harder to get 100% out of your hardware. I would guess that browsers are 3x slower than they could be on most CPU/GPU bound tasks.
bmitc 4y ago
> but I think this is just the cost of the incredible volume of software that we have This may obviously be a personal stance, but I will never accept the excuse of scale for anything. If you can't do it at scale, then you can't do it. Quit scaling and making everything worse. This applies to software, population, consumerism, consumption, etc.
int_19h 4y ago
Looking at the contents of, well, pretty much any app store invites a question: is this incredible volume of software that we have actually useful?

routerl 4y ago

> A better tactic is to pick one very specific area you think you can make a dent and focus on that. Amen. Best practices taught me "don't break extra windows, and repair broken ones as you find them", but I'm finally at a point in my career where I can say, with confidence, that some broken windows aren't worth fixing; you might have enough expertise to know that it should be fixed, while simultaneously lacking the expertise to do so in a cost-effective way. Case in point: in the iOS app I'm currently working on for a client, my team discovered a bug that was, very clearly, an interest payment on the technical debt the client has been accruing. The "correct" bug fix would entail rewriting a lot of existing functionality (i.e. paying down a big chunk of the principal, on the technical debt). This was not cost effective for us, since we were being paid to fix the bug as written. So we fixed the bug, while introducing functionality that could, in the future, be used to pay down the tech debt principal, should the client desire to do so. Spoilers: the client will never desire to do so, and therefore we've actually just added cruft to the codebase. But this conclusion is not allowed, in the client-provider relationship; the bug is fixed, therefore contract conditions have been met, therefore the work is done. The cause of bad software is, simply, that the incentive structures and scheduling required for making good software don't usually exist.

mikepurvis 4y ago
> the bug is fixed, therefore contract conditions have been met, therefore the work is done Agile-type workflows also push toward this kind of prioritization— focus on story points, requested features, value delivered to the "customer", etc etc. It's obviously important, especially if the task at hand is to rein in a team consumed with grand rewrites and architecture astronaut stuff. But at a certain point, the pendulum has swung too far the other way, and you do need competent technical oversight— not just someone who assigns you a sprint or two to "pay down debt", but who engages meaningfully in understanding what the debt is, how it came about, and what the ongoing cost is of carrying it; and who can actually set milestones on the cleanup effort and communicate to the larger organization how it was valuable work to have done.
- andrekandre 4y ago
  > But at a certain point, the pendulum has swung too far the other way, and you do need competent technical oversight— not just someone who assigns you a sprint or two to "pay down debt" yep, if you are truly agile, you will be continuously improving the whole system you are working on otherwise it gets harder and slower to "deliver stories" to your customers... its a balance to be sure.
  - mikepurvis 4y ago
    Oh definitely, but that requires everyone to be on the same page about that, that every feature has a built in overhead of whatever% time allotted to general maintenance. Otherwise it's just a prisoner's dilemma where the one guy who doesn't do any of that work will be at the top of the list for promotion because he gets 30% more done than anyone else, as measured in story points.
    - andrekandre 4y ago
      > prisoner's dilemma where the one guy who doesn't do any of that work will be at the top of the list for promotion because he gets 30% more done i see this so often its not even funny anymore... (insert crying face here)

christophilus 4y ago

> That's why web apps slowly killed native apps I prefer web apps over native for most things. I only trust a handful of native applications on my computer (neovim, Postgres, compiler tooling, stock Linux utilities, etc) Corporate applications are highly suspect to me. I’m not sure why. I much prefer running things in a sandbox like the browser. I also find that my resource usage is lower when I run Zoom, Slack, Reddit, etc in a browser vs their resource-hungry native applications.

walleeee 4y ago

> Useful software today beats perfect software tomorrow. this isn't a natural law, it's a product of social incentives and amenable (if perhaps difficult) to change > A better tactic is to pick one very specific area you think you can make a dent and focus on that. good advice!

BirAdam 4y ago
Useful today is a matter of time preference, and as all software is now essentially free, the cost is computer time you already have available. It may not be a law like a law of physics, but it is an observed law of behavior.

tepitoperrito 4y ago

I dunno, I'm gonna try writing a pattern language to avoid getting tied up with one specific area. Friends can fill in the blanks. https://en.m.wikipedia.org/wiki/A_Pattern_Language https://en.m.wikipedia.org/wiki/A_Pattern_Language

_gabe_ 4y ago

> but I think this is just the cost of the incredible volume of software that we have. But it's not. The author gives specific modern examples of individual people absolutely destroying our concepts of how fast an app should be: >> Work Martin Thompson has being doing (LMAX Disruptor, SBE, Aeron) is impressive, refreshingly simple and efficient. Xi editor by Raph Levien seems to be built with the right principles in mind. Jonathan Blow has a language he alone develops for his game that can compile 500k lines per second on his laptop. That’s cold compile, no intermediate caching, no incremental builds. Jonathan Blow's language compiles 500K lines of code in 1 second! It takes me 20 minutes to do a full build of our monorepo, which is nowhere near 500K lines of code. And it's not even compiling and optimizing and linking, it's just transpiling typescript to javascript. It's ridiculous. It's ridiculous to think we can't do better. Another case in point, modern games can render millions of polygons now (with UE5) at 60fps. And a modern web browser can hardly render some of these static web pages on my PC with an RTX 2080 and 48GB of RAM at 60FPS. Something is seriously wrong with our ideas of "performant code" if we think this is acceptable.

kvark 4y ago
I worked on both games and browsers, and I’ve seen this comparison being made before. Browsers are way more complex than what meets the eye. There are requirements for high quality text, page consistency, lots of different content types, fine 2D graphics, network ops, and multiply low power consumption requirements on top. WebRender is somewhat a game engine. Real games are happy to cut all these corners, for the sake of bring impressive, and they mostly rely on hardware-accelerated functions.
- thethirdone 4y ago
  I think web browsers could get framerates on typical webpages to 180 fps if it were a priority. I have found some sites that should be renderable at super high framerates that struggled to keep an average of 60 fps. One reason that browsers aren't super fast is that it will always be possible to make a super slow site. Speeding up sites like HN is really not very important to battery life or user experience. Also the necessary complexities of the browser make it much harder to get 100% out of your hardware. I would guess that browsers are 3x slower than they could be on most CPU/GPU bound tasks.

bmitc 4y ago

> but I think this is just the cost of the incredible volume of software that we have This may obviously be a personal stance, but I will never accept the excuse of scale for anything. If you can't do it at scale, then you can't do it. Quit scaling and making everything worse. This applies to software, population, consumerism, consumption, etc.

int_19h 4y ago

Looking at the contents of, well, pretty much any app store invites a question: is this incredible volume of software that we have actually useful?