Enough with the movements

Wrong book. Try looking at a history of science. You definitely see the same sort of behavior. A good place to start is Kuhn's The Structure of Scientific Revolutions. If anything, science is worse because the cycles are longer. As Max Planck wrote: "A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it."

There's a huge confusion between the movement as a whole, and the movement at the individual level. What exactly is stupid: the fact that some people sell bullshit seminars about a new fancy programming paradigma or the fact that some people try to improve themselves by looking at the new tools out there?

Movements are just the inevitable by-product of an underlying phenomenon: people are attracted to the next shiny things. Note that I said "people", not just Hackers/Programmers. Actually, a lot of the hype around the new tools does not come just from the Programmers, but is carried by management as buzzwords.

But complaining about "movement" misses the point. Those who currently wrap these concepts around layers of bullshit in order to sell books and certifications are not going to stop doing it anytime soon. Should we stop buying the books? Well that would be throwing the baby out with the bathwater. As the OP said, there often is a kernel of truth in these new methods, and although it is annoying for us to have to skim through all that noise, I don't think that ignoring everything new is the right thing to do.

"...very little of what I've learned that's genuinely important wasn't known about and written about before I was even born."

The problem here is to know what is genuinely important. I guess the only thing that's genuinely important is what makes a turing machine: the rest is just some extra layers. But detail matters a lot. The reason why there are so many different languages / paradigmas is because different tools are more adapted to different problems. I'm not a big fan of OOP, and I never use it ... unless I think that it is absolutely obvious that objects are the right thing to do (which is pretty rare).

I'm on board with the movements sucking part, but the "more complicated" argument is a strawman. Chess and physics are completely different from software engineering. Chess is different because the goal is strictly defined. Physics is different because it's attempting to describe a set of timeless, immutable and readily observable truths about the physical universe.

The problem with software engineering is that experimentation is very difficult. You can come up with all kinds of theories, but they are impossible to test in any kind of objective or reproducible fashion. Plus, even if you come up with something that seems universally true, it's not universally applicable. For instance, we know that NASA's dev process produces fewer bugs than other processes, but at a cost that's several orders of magnitude higher than typical business software development. In practice you care about concrete ROI and tradeoffs, so you might be interested in knowing whether unit testing or very strict static typing (eg. Haskell) is more reliable at preventing bugs. But even if you had unlimited time and resources to analyze all possibilities, I think you'd find it's heavily dependent on the type of software you're writing, and the types and applications of software are not stable or categorizable.

In short, software is not more complex, it's just less constrained. Software engineering is more like mathematics than chess, and more like economics than physics.

    ... at the core of every movement, there's a little kernel of almost
    universal truth ... become enshrouded in a shitload of meaningless
    gobbledygook ... miss the underlying point completely

    ... there also tends to be a small kernel of software developers who
    actually get it.

    True evolution and progress in software development ... will require
    us to drop the brands, dump the fads and the fashions, and focus on
    what we know ...

I would say that software engineering is actually closer to architecture. Architecture has a solid basis built on science (otherwise the buildings won't stay up!), but a lot of it is being constantly refined through various movements. I don't think that its that surprising that software engineering got design patterns from architecture!

Maybe Software Engineering is waiting for it's own Francis Bacon. Software Engineering is a young 'science' and the natural sciences went many hundreds of years before their watershed moment.

Of course then their is the argument that Software Engineering is a misnomer altogether and in fact it's an art/craft and well art is filled with movements all of which are untestable and (in)valid to the same extent.

Personally I think that Software Engineering is hard and most people are not up to the challenge and they latch on to movements as a safety net. Actual (real world) Engineers are weeded out during training in universities. We seem to let anyone call themselves a Software Engineer/Programmer and to be honest a lot of the ones I meet are well below par.

"Movements" or "schools of thought" are common in one form or another. It happened in psychology with Freudian, Neo-Freudian, Behaviourism, and finally the Cognitive revolution, which transitioned into the modern merging of psychology and neuroscience. It also happened in mathematics with the Liebniz vs. Newtonian schools of calculus, and countless times through the entire history of philosophy.

When future people look back at the state of Physics in the 20th century to the present, I think they'll see it too with the split between relativistic physics and quantum mechanics as an explanation for how the universe works.

I'm sure there are countless other examples. My point is that this isn't unique to computing. It's a common phase for a field to go through -- perhaps every field does at the beginning. Some fields transition out of this state and become stable, with a kernel of very solid principles and new development around the periphery. Others, like philosophy, are stuck in this state seemingly indefinitely. That kernel never develops.

The only question is when will it end in computing? What will that kernel be?

When I picture a proper, professional, employed software developer, I think of somebody who follows a "Right tool for the job. Go with what you know. Don't get caught up in the razzle dazzle" kind of philosophy/attitude.

Just seems like a lot of people in the industry don't always think this way, and I often wonder where/how they actually put these fantastic new technologies to use in the real world.

The underlying concepts in computer science ARE simple, but the problem is that your average developer deals less with them and more with higher level concepts. In fact, you might argue that at this point computer science is ALL about the complexities we have introduced. We are not writing assembly anymore, and we kind of have to deal with the unfortunate reality that computer science is going to be needlessly complex for some time to come, thanks to poor (or lack of) standardization (yes, I would throw every web standard in this bucket). Needless to say though, I agree that we should find a way to simplify things (if that is possible).

Movements are not about the subject matter or the business that develops around it but about people who are interested in the subject matter. Movements are about how those people interacts and go about discovering, leaning, improving and interacting.

As such stating that they are stupid is...errr..stupid and kind of shows that in this case you are doing exactly the same mistake you are (correctly) complaining about: you don't know enough about the body of knowledge called Anthropology that came before you.

also: just because you don't see the movements in sciences like physics doesn't mean they are not there. You are comparing an extremely young thing (software engineering/CS) with sciences that have been going for centuries (and more). You need to study the history of science in order to be able to see the movements over the centuries (and it's plausible that after a few centuries movements become slower/longer)

I understand there are movements behind these conventions, but I wouldn't say these conventions are stupid.

- indirection

- abstract data types

- awareness / isolation of mutable state

- choosing the time of evaluation

what else? i am trying to get the fundamental, simple issues that underly "movements" or allow us to manage complexity (many gof "design patterns" seem to reduce to the above, for example). although i am not sure what movements encapsulate the above...