Enough with the movements(codemanship.co.uk)
codemanship.co.uk
Enough with the movements
http://codemanship.co.uk/parlezuml/blog/?postid=1101
15 comments
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)
> 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)
"A short history of nearly everything" by Bill Bryson is an entertaining read with numerous funny stories behind some scientists/discoveries. Definitely a more lively take than a textbook that presents the end results and omits the process (not to fault said textbooks as that is what they intend to do).
[deleted]
Science evolves from funeral to funeral.
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).
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).
> 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.
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.
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.
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.
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?
The thing to do, is to focus on real value. That's hard sometimes and very natural other times. What empiricism works in software?
Or, since it's universally market forces which are responsible for this corruption, block them from being able to profit off the idea.
The problem there, is that the same dynamics occur with non-monetary compensation. (Or indirect monetary compensation.)
>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?
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?
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_...
I think the marketing and dumbing down phenomenon has happened with languages. However, there, proprietary software also fares worse. You may have a point.
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_...
I think the marketing and dumbing down phenomenon has happened with languages. However, there, proprietary software also fares worse. You may have a point.
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!
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!
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.
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.
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?
"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?
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.
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.
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).
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).
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)
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)
[deleted]
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.
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.
I understand there are movements behind these conventions, but I wouldn't say these conventions are stupid.
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...
- 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...
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.
Is there a list somewhere of concrete things that we know about software engineering?
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."