What I don't understand with both Muratori/Blow is that they seem to be incredulous that someone wouldn't just make software high quality and fast for the sake of it

Like they can't comprehend the fact that these things only happen if there is an incentive for it

I think its because they work in games where there is a business incentive for performance, users care a lot if framerate suffers in a game

They are so used to working in games that they take it for granted that the business incentive for performance exists

As someone who has worked in both AAA games and big tech it just comes across as a bit naive to me

▲

softwaredoug 20 hours ago | parent | next [-]

I think there could be a version of our industry with people doing better work. And it’s worthwhile to study why we don’t have that industry.

Yes it’s incentives - but why these incentives exist and not others is an interesting question to study.

In the 2010s we pushed everyone to learn how to code and maybe lost some of our higher standards. Maybe we’re doing that now with AI?

Maybe broader social and economic incentives have had a lot of short term thinking of late? It’s hard to organize society or a company to go in one direction very long before incentives completely change everything. Who knows, maybe that’s a feature, not a bug.

It’s worth asking though why we have this software industry and not another one. I’m not convinced it’s for legitimate reasons.

▲

stereolambda 20 hours ago | parent | prev | next [-]

I think the thesis would be there's a colossal structural/market failure in software. This because of many degrees of freedom, consumer ignorance, network effects and such. Compare this to physical things. The difference between the absolutely shoddiest couch sellable and the practically best one is tiny, compared to the difference between the worst software you could impose on the market and what could be achieved by competent engineers if we somehow removed the wrong incentives from capital and bureaucracy. With most software most people use, we are near the bottom of this range. I don't know if I fully buy that, even if we completely ignore whether removing these incentives is at all realistic. But would also say there's something there.

Then we can talk about how we all pay the increased cost in energy and materials, and so forth.

▲

groundzeros2015 19 hours ago | parent | prev | next [-]

The fallacy is assuming it takes more work to get good performance. When what’s really lacking is clarity about the problem and solution.

Optimizing code for max performance does take work. But just not doing incredibly dumb things and writing simple programs just takes education (and re-education).

I can’t count how many times I’ve replaced a distributed system with for loop.

	▲	DanielHB 4 hours ago \| parent [-]
		You are assuming a greenfield scenario, in large brownfield projects it is quite easy to degrade performance by innocent changes. That is usually when the perf goes to trash. It takes a lot more work to keep performance good in a large project than just letting it degrade.

▲

danpalmer 17 hours ago | parent | prev | next [-]

Setting aside incentives – because I think that's very fair to push back on, we should strive for better craft...

I find Blow in particular a bit naive when it comes to the complexity of modern non-game software. Games are very complex, but Blow puts them on a pedestal separate from other software, as if a web backend can't be as complex. He calls software slow while simultaneously ignoring most of the functionality.

He's essentially never had to deal with distributed systems, or anything that allows multiple users to use the same system, with all the performance and anti-abuse issues that come with that.

His opinions about game development are insightful, and his thoughts on craft can be quite inspiring, but I think he could benefit from a stint on a (good) big tech server team to see some of the things he's currently missing.

▲

ButlerianJihad 17 hours ago | parent [-]

Heh heh heh. In actuality, Jon Blow has plenty of experience with distributed and multi-user systems. I worked closely with him while we were developing TinyMUCK 2.x, and the MUF programming language, a stack-based, simplified Forth.

In fact, Jon played a crucial role in the invention of the first MUF worm. We had just finished an extension to MUF that permitted triggering programs wherever a text string was expected. This gave a great flexibility and functionality to run MUF programs passively, by third parties, all kinds of new ways.

Unfortunately this also gave rise to a "worm" type of MUF that replicated itself whenever it was triggered passively. We went a little crazy when this was discovered, but it was all part and parcel of a multi-user game system, where there were permissions to consider, and multiple read/write/execute access to objects that should be owned by their respective player characters.

Jon Blow also inspired a lot of my exploits as I tested other systems of MUD programmability. In that time, TinyMUSH was also experimenting with a language that was more akin to scripting, and boy was it vulnerable. TinyMOO was also coming out, with a rather revolutionary programming paradigm. So in the mid-1990s, just in the insular TinyMU* world, there were at least 3 branches of programmable MUDs being actively developed.

Hopefully Jon could recall my greatest contribution to the corpus of early MUF programs. On Atlantis MUCK, I programmed a simulation of Conway's Game of Life. Of course, there was no animation possible and there was no multithreaded execution possible, either. So my program was given a starting board of Life, and then computed each frame in sequence, output it into the text stream of the game, and terminated after N iterations. Meanwhile, the entire game server locked up, because it could only run one MUF program at a time. Everyone else's commands and input would be held until my MUF program finished running.

This was a real issue, of course, and Jon and I worked to mitigate the problems caused. I think, ultimately, we just limited the number of iterations or the number of instructions that could be executed by any one MUF program at a time.

But Jon and I collaborated on a tutorial for player-programmers, and he helped us find and extinguish many bugs. And these were very complex systems, with 64 or even 256 simultaneous players.

Perhaps Jon has forgotten some of those lessons, but perhaps not.

	▲	danpalmer 16 hours ago \| parent [-]
		Fair enough! That's some good experience and should address some of what I've heard from him, but perhaps he has forgotten. That said, and this is coming from someone who (sadly) missed the era of computing you're describing, I think there's still a difference between dealing with a 64-256 player multiplayer system, and scaling a server application across dozens? thousands? of machines, across the world. My limited research suggests that MUDs run almost exclusively on a single machine (?), or even just having a small number in one location drastically simplifies the problem space.

▲

Aeolun 17 hours ago | parent | prev [-]

I mean, it’s a thing in pretty much all lower level software that you want it to be fast. I guarantee you postgres and redis are trying to optimize the software to the cycle, because wasted cycles are wasted for all their users.