Enough with the movements

This is not too long, and it's definitely worth reading. Here are some highlights:

    ... 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 ...

Sturgeon's Law again. The way it works, is that a small core of people understand an idea, an aesthetic, a new mental system, and they create real value with it. However, the reputation of the new thing grows into hype, which is then exploited for marketing purposes.

The thing to do, is to focus on real value. That's hard sometimes and very natural other times. What empiricism works in software?

> We've made it much more complicated than it needs to be. It's a lot like physics or chess (both set-theoretic constructs where simple rules can give rise to high complexity, just like code): sure, it's hard, but that's not the same as complicated.

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.

As an 'amateur developer', when I read articles about these new 'movements' I often wonder about the authors who write them. All I ever think is "Wow, this person must have a really cool job with awesome, care-free managers who don't mind letting their staff run wild with the latest and greatest framework/language."

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.

It's not even about being complicated, the flaw in the argument lies in "What is true is true. If we keep testing it and it keeps working, then the insights hold."

It's essentially the difference between science and engineering, and why so many people who are good scientists have trouble being good engineers. What is true today may not be true tomorrow when people are involved. Engineering is applied science. Applied by who? People.

The human brain is the universe for us, and it's not nearly as static as the universe that scientists work in. Brains learn, they adapt, they get bored and lazy, sometimes they make irrational decisions. They act differently depending on if/where the brain went to school, and what it had for lunch, and what the economy looks like, and how shiny an object is. That's what we're dealing with, and why there are so few "truths" in the field.