

Enough with the movements - SanderMak
http://codemanship.co.uk/parlezuml/blog/?postid=1101

======
wpietri
> When I flick through my textbooks from my physics degree course, they don't
> read as a series of cultural movements within the physics community. What is
> true is true.

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

~~~
pm90
agreed.

 _> When I flick through my textbooks from my physics degree course, they
don't read as a series of cultural movements within the physics community.
What is true is true._

This is actually something that is done deliberately, because the situations,
conditions, debates, culture etc.etc. are seen as a distraction from the main
objective- to learn physics. The actual history of science is more
revolutionary than what many might think- sure there are no wars; but the
paradigm shifts that follow the introduction of new ideas is what I would call
revolutionary (Interestingly, I believe the term 'revolutionary idea' came
about after the discovery of the heliocentric nature of the solar system; i.e
the idea that earth goes in 'revolutions' around the sun rather than it being
stationary)

------
abraxasz
I disagree.

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

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

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

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

~~~
stcredzero
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?

~~~
Produce
Or, since it's universally market forces which are responsible for this
corruption, block them from being able to profit off the idea.

~~~
stcredzero
The problem there, is that the same dynamics occur with non-monetary
compensation. (Or indirect monetary compensation.)

~~~
Produce
>same dynamics occur with non-monetary compensation

In my experience, at least with Open Source Soft/hardware, this does not
appear to be the case. Are you referring to a particular study or incident?

~~~
stcredzero
Non-monetary (direct) compensation: Some entity gets famous doing something
which they're not paid for, but parlays the fame into economic gain.

FOSS example of notoriety (non-monetary compensation) later resulting in
money: GCC has some benchmarks that are better than vendor compilers.
Companies that use GCC start paying to improve it. The thing is, GCC is pretty
good, and deserves its good reputation.

However, the notion of "Open Source" itself has been subject to hype.

<http://news.cnet.com/8301-13505_3-10295530-16.html>

[http://www.foreignpolicy.com/articles/2006/05/25/beyond_the_...](http://www.foreignpolicy.com/articles/2006/05/25/beyond_the_open_source_hype)

I think the marketing and dumbing down phenomenon has happened with languages.
However, there, proprietary software also fares worse. You may have a point.

------
chris_wot
Comparing software engineering to physics isn't entirely a fair comparison.
While there is a solid basis for scientific principles, there is a lot of art
in software engineering.

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!

------
dazzawazza
The comparison with physics is interesting. If you look at physics (or
science) before Bacon it could be considered as a set of movements and people
'believed' things. Post Bacon and the Baconian method people tested and
verified. This had the effect of unifying people behind testable facts.

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.

------
a-priori
_My question is, do we need movements? When I flick through my textbooks from
my physics degree course, they don't read as a series of cultural movements
within the physics community. What is true is true. If we keep testing it and
it keeps working, then the insights hold._

"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?

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

------
gavanwoolery
Great article, but one caveat:

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

------
ABS
the problem is that you are, IMHO mistakenly, conflating at least thee
different things: movements, the subject matter and business around them.

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)

------
v21
The usefulness of each movement isn't that they're right in themselves. It's
that when the hype has faded, and they wash out again, the landscape they
leave is different. If they're successful, half of what they advocated is seen
as hyperbole, and half of it is taken as common sense.

------
andrew_wc_brown
I use all of these programming conventions and take them with a grain of salt.
To say they're stupid is stupid.

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

------
andrewcooke
so what are the core things? some suggestions:

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

------
ericHosick
The software industry today is where the medical industry was 200 years ago.
We still have a long way to go and a lot of movements to look forward to.

------
koningrobot
Is there a list somewhere of concrete things that we know about software
engineering?

