Software Disenchantment (2018)

But the best explanation for why this problem persists even in teams of proficient engineers that I have seen comes from the 2005 GDC Keynote from John Carmack [1].

> I can remember clearly in previous projects thinking [...] I've done a good job on all of this but wouldn't it be nice if I could sit back and really clean up the code, perfect the interfaces, and you know, just do a wonderful nice craftsman job [...] interestingly this project I've had the time to basically do that and I've come to the conclusion that it sort of sucks [...] there's a level of craftsman satisfaction that you get from trying to do what you do at an extreme level of quality and one thing that I found is that's not really my primary motivation [...] that's not what's really providing the value to your end-users [...] you can sit back and I am do a really nice polishing job it's kind of nice but it's not the point of maximum leverage and I found.

So, as others have mentioned here, there is a threshold where extra performance provides less value to the project than, say, an extra feature.

It seems that in some cases we have crossed that threshold and some software has become comically bloated. I attribute the reason why these are not solved to the same reasoning. Refactoring an existing project to reduce the bloat would take too much time and effort from one single developer, that could be used somewhere else, although in the end everyone would benefit from it. So you are better off adding stuff to the dumpster fire and moving on.

It's sort of a tragedy of the commons [2] of software performance.

[1] https://youtu.be/N0auhzHZe5k?t=1015

[2] https://en.wikipedia.org/wiki/Tragedy_of_the_commons

No one's forcing you to use a library. But if you do they come with tradeoffs.

OK, things are slow and buggy. But we've got lots more things thanks to all the productivity we've gained from using libraries, etc. That means we collectively solve more problems for more people.

Purism is a nice idea, but ultimately probably not worth the effort until things become so bad that they are, and at that point become a differentiator. I mean, I don't care if a web page is twice the size of Windows 95 because my computer is way faster than a 486.

It's understandable people want to base their decisions off empirical evidence. But it's important to remember that what you measure (vs. what you don't measure) and how you measure will determine the path you're going as much as the results of these measurements.

React is huge, it’s unlikely you’ll implement the synthetic events, lifecycle hooks, bottom up updates, context, hooks with their magical stacks, rendering “optimizations” and all of react-specific warts.

There are simple reimplementations like hyperapp and preact and I completely recommend using those instead. I really meant React the library and ecosystem are at fault, not the general model.

Secondly we talked about 0.005l cars, not 0.05l, so it would be a few hundreds times more efficient than train transportation.