[rightbyte]

> software development has gotten infinitely easier in recent decades.

I don't agree here. It was way simpler in the 90s. The programmer experience probably peaked around the transition from TUI:s to win32 where you could do either. Different screen resolutions is probably what made programming gui:s suck. And all the churn of Microsoft and Oracle frameworks didn't help.

Nowadays the overhead of making an app that passes procurement is insurmountable. And consumers seem to not buy apps at full price anymore.

[EasyMark]

Why can’t they just decide on a framework and stick with it, warts and all? My God Microsoft is the worse for this, how many .Net frameworks do they have out? I’m glad I’m “stuck” back the world of “simple” Qt GUI and lower level embedded stuff.

[rachofsunshine]

Design and framework churn is a sort of conspicuous consumption. It's not that, taken literally, your 1997 geocities site has gotten any worse - it's that making something better is so trivial that if you don't make something better you look like an idiot / someone without resources / totally un-self-aware.

[tester756]

Yea, because C++ world is known for having one, sane thing instead of 10 inconsistent.

[johnnyanmac]

I think that's why the Paradox works. Doom was a technological power house in the 90's. Created by 5 people in 15 months.

Techs advanced enough that you could make a facade of doom by yourself over the weekend (game design aside). Game devs can be so incredibly productive. But instead, demand sweeled to insatiable heights, as well as dev teams. Doom 2016 probably had hundreds of staff involved and 4-5 years of dev time.

That's basically what happens when tech aims to be bigger and better instead of how to optimize each dev themselves to be individually more productive and keep the project lean (company structures aren't helping either).

[adventured]

> That's basically what happens when tech aims to be bigger and better instead of how to optimize each dev themselves to be individually more productive and keep the project lean

Comparing Doom 1993 vs 2016 makes no sense in that context. There's no scenario where you make gigantic scale Doom-style game worlds circa 2016 with even 20-30 people, much less 5-10. Art asset creation alone for 2016 requires far more staff than the original Doom. Optimizing each dev wouldn't begin to scratch the surface in terms of what you need to get to Doom 2016 if we're talking a dozen people or less. You'd need extraordinarily advanced AI agents creating for you, and the year would need to be more like ~2040-2050. The tech underlying a game like Doom 2016 is a modest part of the labor scale problem.

[johnnyanmac]

> Optimizing each dev wouldn't begin to scratch the surface in terms of what you need to get to Doom 2016 if we're talking a dozen people or less.

What do you think comes to mind when you hear "optimizing each dev"? My suggestion was for each dev to work wider, not deeper. There'd inevitably be a hit in raw fidelity, but that's part of the point I wanted to make.

Of course, no amount of automation even with AI will make up for millions of hand crafted man hours. But my big discrepancy with modern game dev is: for how much business want so care about costs and skimping on labor, we go far, far past middling returns in order to deliver these AAA games. I'd definitely wager that you could preserve 80% the quality of Doom 2016 with 20% of the staff (and pay that staff better, not just pocket the 3x cost reduction) and it would still look top of the line. Even then I question the middling returns.

There are good and insidious reasons why it's so rare, but I was really hoping these better tooling over time would produce more indie studios able to work at around a AA level of production. 5-10 people making games that really aren't that vast a gap from AAA presentation to the common consumer. Instead that sector is seemingly shrinking. It's a problem I at least want to try and chip away at in my career.

[rachofsunshine]

That's not that development has gotten easier, it's that the bar has gotten far higher. The fact that e.g. responsive UIs and multiple input methods and the like are possible is a consequence of the fact that development is so much easier you can afford to spend resources on such things.

What you're citing is an example of the Jevons paradox, not a counterexample. Development got easier, so demand for (more depth and variety of) development rose.

[entangledqubit]

While I agree that development has gotten more complex (often unnecessarily), compared to the 90s, the sheer number of potential consumers now available seems hard to justify complaining about.

[jaggirs]

Nothing is stopping you from using 30 year old tooling if you think it is better than today's

[acuozzo]

The tools (and environments!) 30 years ago were better suited to solving the problems of 29 years ago than the tools are today in solving the problems of the upcoming year.

Specifically, our target environments distance us too greatly from the problem(s) being solved on the main/"happy" path.

Is there a WYSIWYG GUI builder for WWW/Android/iOS as good as Delphi was for win32 or Interface Builder for NeXTSTEP?

If not, then I have to waste a ton of time working on UI boilerplate code instead of the important & fun stuff.

[jaggirs]

> The tools (and environments!) 30 years ago were better suited to solving the problems of 29 years ago than the tools are today in solving the problems of the upcoming year.

A.k.a. The problems have become harder (stricter requirements, more ambitious objectives), which is entirely different than the tooling having become worse.

[acuozzo]

I didn't state that the tools are worse. It's just that they're not as well-suited to the problems we're solving now than the tools 30 years ago were to the problems we were solving then.

The tools themselves are better in so many ways. They just haven't caught up to what we're trying to do with them. Myself, and others, remember fondly when they had.