[spamizbad]

> Nah, that's like wondering why is this ice block sitting on a hot plate and still solid. The answer is: because it just got put there, and it'll melt in a moment. So too, will end high salaries, as most low-hanging fruits get eaten by software, made by mass-produced cohort of programmers.

Our industry has its share of cycles, but this, in my view, is largely wishful thinking on the part of people. Nothing wrong with optimism but...

Every 5-10 years there's a "technical shift" that forces everyone to reevaluate how they build software or more importantly what they build, and the race starts all over again. The ice block is removed from the hot plate is replaced by a bigger, colder block of ice. And when these technical shifts aren't taking place, the bar for what constitutes as "good software" inches upward.

If your standards for acceptable software were frozen in time in 1985: using modern hardware and software toolchains, you could accomplish in one day what used to take a small team an entire month. But if I delivered, say, what passed for a "good enough" database in 1985, it would resemble someone's 200-level CS final project rather than a commercially-viable piece of software.

[kerng]

I have not noticed these technical shifts per se. What I have noticed is that mature engineers move on and do other things and new ones reinvent the wheel with some new fancy language or term which then becomes the new way of doing things, and the cycle repeats. Sometimes there is a great deal of value when a new level of abstraction happens but I wouldnt call this a shift, it's just progression.

Many of the underlying problems and solutions exist for decades. Database systems you mention are a good example of this.

[spamizbad]

When I talk about shifts, I'm referring to things like the proliferation of smartphones and tablets, which increase the net-demand for software and along with an entirely new specializations of knowledge.

While there are some key concepts to things like databases, the fact remains that your 1985 database would not be considered sufficient in todays world: It would have too many limitations, lack features we now take for granted, would not scale to modern data requirements, etc. Supporting all that "modern" functionality is non-trivial and requires a huge amount of effort. You can't just say "Well, we figured out space and computationally-efficient hashing, so relational databases are well on their way to being feature-complete"

There's a reason we haven't stuck with 1.0 on our platforms, and it's not just security or a desire for a bigger version number: New demands required new functionality and new ways of building things.

[jimbokun]

"When I talk about shifts, I'm referring to things like the proliferation of smartphones and tablets, which increase the net-demand for software and along with an entirely new specializations of knowledge."

iOS was basically AppKit, so anyone already developing for the Mac knew most of what they needed to know to develop for iPhone.

Pretty much every programming innovation is incremental, and doesn't require throwing out all of your previous knowledge and starting over.

[JKCalhoun]

> iOS was basically AppKit, so anyone already developing for the Mac knew most of what they needed to know to develop for iPhone.

Maybe. But AppKit was not the Mac Toolbox.

When my career began being good at memory management was a skill to be proud of. I would say now, being good at concurrency is a skill to be proud of.

I don't really have to worry about memory management any longer but didn't worry about threading when I started my career.

As I see the younger generation entering the programming field I wonder in what ways the craft will be different when they've had a few decades under their belt.

Will parameter tuning datasets for machine learning be the coveted skill? Who knows.

[pennaMan]

>so anyone already developing for the Mac knew most of what they needed to know to develop for iPhone

But the demand for developing in AppKit suddenly increased by orders of magnitude.

[convolvatron]

i'll just leave this here https://books.google.com/books/about/Distributed_Databases.h...

[nostrademons]

MongoDB didn't become a public company through innovations in fundamental distributed database technology or even through good engineering. They became a public company because once Javascript became adequate for building client software, there was a strong incentive to build MVPs using the same data structures from client to server to DB, and once you build an MVP that gets adoption there's a strong incentive not to switch databases.

That's the sort of shift in the environment that the grandparent is talking about. Fundamental CS tech was arguably better in the 1970s and 1980s, because it moved more slowly and you had time to get the details right. That doesn't matter if you're building say a mobile Ethereum wallet in 2018, because you're building for the user expectations of today, they don't care about data integrity or security as long as it doesn't fail during the period where they're deciding which tech to use, and software that solves the problem (poorly) now is better than software that doesn't exist.

[vkou]

> Fundamental CS tech was arguably better in the 1970s and 1980s, because it moved more slowly and you had time to get the details right. That doesn't matter if you're building say a mobile Ethereum wallet in 2018, because you're building for the user expectations of today, they don't care about data integrity or security as long as it doesn't fail during the period where they're deciding which tech to use, and software that solves the problem (poorly) now is better than software that doesn't exist.

I believe you are a victim of survivorship bias.

There was plenty of shitty software in the 70s and 80s. The difference between then and now is that we haven't been able to wait for 4 decades, to see what software of 2018 stood the test of time.

[kerng]

I agree, back then there was not a mindset of move fast and break things. It was foundational research, a lot results and learnings from then are still applicable today.

[ams6110]

> software that solves the problem (poorly) now is better than software that doesn't exist.

That has always been the case and is about as good a one-line summary of the software industry as I can think of.

[fnord123]

It could be a one line summary of Richard Gabriel's famous essay "The Rise of "Worse is Better""

https://www.jwz.org/doc/worse-is-better.html

[chrisco255]

Done is better than good!

[tracker1]

But on the flip side of that slow movement, you wind up with things like Oracle... for good or bad.

[jskaggz]

And the mainframes that run our banks, transportation systems, healthcare, public safety.. etc etc. Use the right tool for the job, price it against what the market will bear. Pacemakers and insulin pumps driven by npm updates - shudder -

[joshuamorton]

This predates the formulation of the cap theorem by ~15 years, so I doubt it contains everything relevant to a modern distributed database.

[eropple]

It's before my time, but I'm pretty sure people had at least an intuitive understanding of what partitioning does to a datastore before Eric Brewer wrote it down.

[kerng]

I'm not sure why you get downvoted, I'll upvote you.

The "modern" database systems are now going back to the exact design principles that the books you refer to solved long time ago. There is tons of research, dissertations,.. that focuses on this from decades ago.

Its just now that the new systems realize that these problems actually exist.

If you dont know the history of a certain field and what came out, you repeat and make the same mistakes again. This seems to also apply to software engineering.

[RhodesianHunter]

I can assure you that the major theories behind modern big distributed databases were not written in decades old books.

[kerng]

Yeah, distributed database systems from the late 70s, early 80s actually had certain transactional guarantees that some of these "modern big distributed systems" you refer to still dont have.

[sedachv]

Yes, some of those theories were also applied in decades old systems. Look up Tandem Computers and Teradata.

[lumost]

In maturing parts of the software industry you'll often see a desire to stay with the times in order to maintain a competitive edge, re-inventing the wheel often looks like full/partial re-writes of a system for minor marginal gains.

A great example of this is the evolution of FB/Google/Amazon. Portions of their core tech have been completely re-written over the years for marginal gain, but there is a large premium to being the best in tech.

In other parts of the industry every new cycle enables some new area of tech, and those marginal gains become the minimum bar for entry. e.g. Deep Learning and Computer Vision, distributed systems and cloud computing/SaaS.

[hopler]

You overestimate the quality and reliability and expandability of those old systems. The 1998 10 Blue Links tech couldn't support the functionality and scale of Google today.

[gaius]

your standards for acceptable software were frozen in time in 1985

Haha in 1985 Amiga had a multitasking GUI desktop in 512k and 7Mhz. Now we have millions of times more computational power and struggle to deliver an experience as crisp and satisfying.

I wish people still made software like it was 1985, that actually used the full power of the hardware for something useful...

[spamizbad]

Yeah but Exec/Kickstart/Workbench was missing some basic niceties that are table stakes today:

- No process or kernel security (processes could rewrite kernel code)

- Processes could effectively disable the scheduler

- Supported only a single, fixed address space: both a massive limitation and a performance hack that made the system bearable to use

- Single-user

- No security model

There are embedded applications these days where not having these features are deak-breakers. Let me assure you: if you re-implemented the original Amiga OS feature set it too will be screaming fast. The tricky part is keeping it fast once you start adding protection and additional functionality on top of it.

And largely what happened when you tried to implement more complicated applications on top of these primitive systems is that they would crash the entire system, constantly.

[makapuf]

That and the fact that amiga was clean room design. IBM Pc was already old and even x86-64 won over itanium. Backwards compatibility has a cost but also gains. Amiga wasn't even compatible with c64.

[gaius]

That and the fact that amiga was clean room design. IBM Pc was already

Well the PC wasn’t backward compatible with CP/M so that’s an odd critique to level at the Amiga.

[makapuf]

Sure but "pc" at the time of amiga was already pc compatibles and at backward compatible with xt and IBM PC. Besides amiga was very optimized for 2D graphics. 3D story has been less rosey. But I would seriously welcome a new amiga. That wouldn't mean a specced up amigaos running pc. That would mean a radical new mobile architecture. Or Vr machine. Some fresh air On a radical, alien architecture. Belt CPU ? Gpu/CPU à la xeon phy ? Ram only? Dunno. Something crazy.

[pjmlp]

Itaninum only lost because Intel did the mistake to allow AMD to design x86 chips.

[makapuf]

That would mean itanium could have won only by a monopoly and that with open competition, backwards compatibility won.

[pjmlp]

Itaninum also had an emulation mode, while not perfect, they could eventually improved it.

Backwards compatible didn't matter in the mobile world, or for those screaming for ARM laptops.

Sometimes we can't just have nice things.

[gaius]

more complicated applications on top of these primitive systems is that they would crash the entire system, constantly

That’s chicken-and-egg. Why do modern apps with actually quite simple functionality need all this vast power, the GHz and Gb? Because it’s there. Why does software crash? Because the OS let’s it with nothing more than inconvenience to the user.

Amigas were actually quite usable, they were stable enough for complex software to be developed and real work done. Same for ST’s.

[gcb0]

your whole point is extremely backwards! software in 1985 was more "complete" than today. Even CD roms shipped with magazines had to support more windows variations than "good software" today supports of browsers! not to mention that every corporation with a software team also had usability and QA teams. Software quality and resiliency was much better than today. Then in the 90s it took a dive because online made "first to market wins", and it have been downhill from there.

so, your software concepts from 85 would be overkill today, not lacking.

[antt]

In 1985 you target one machine with one thread and one level of memory.

Today I'm working on systems with memory latencies from l0 cache all the way to tape storage. And it's getting worse.

[pjmlp]

Not when coding machines like the Amiga.

[zrobotics]

Agreed, and the games industry may be the clearest example of this. In 1985 the developers had to actually ship a finished game, there wasn't the opportunity to release a half-finished product and update it later. Compare to Fallout 76, which was very clearly unfinished at launch.

Edit:typo

[hopler]

Games in 1985 shipped with bugs baked in that people were just stuck with. Civilization had a broken Gandhi, and still shipped 4 different bugfix versions.

[zrobotics]

No game (or any large software project) is ever bug-free, but the standards were higher than they are now. Fallout 76 was literally unplayable on launch-a fairly early mainline quest was broken, so it wasn't possible to reach the endgame. Was civ unbeatable on release? Sure, ghandi was bugged, but that was entertaining enough they kept the bug in the sequels.

[dtech]

There were plenty of bad and buggy games in the 80's, it even crashed the market [1]. We just don't remember them.

Also modern non-indie games are orders of magnitude larger and intricate than 80's games, and have about the same distrubution of quality/bugs. They're now made by teams of size 10-1000 rather than 1-10 though.

[1] https://en.wikipedia.org/wiki/Video_game_crash_of_1983

[dmd]

Neither Civilization nor Windows existed in 1985.

[icedchai]

Take a guess when Windows 1.0 was released.

[dmd]

> "software in 1985 was more "complete" than today. Even CD roms shipped with magazines had to support more windows variations than "good software"

There was one variation of Windows in 1985. (And I remember installing it!)

[hnzix]

The anecdote is they deliberately left in nuclear Gandhi for the lulz.

[packet_nerd]

> inches upward

I wish it inched upward... So much software now-days is bloated crap.

[ralphc]

Preach, brother/sister! My career started in the early '80s and I say this all the time in comments here on HN. You had less to work with but less was expected of you.

[sethammons]

I think you analysis is fair, but Glassdoor data is a bit off. At my work, I filled out salary data on Glassdoor and it never showed up. Maybe they thought it too high?