Intellectual Masturbation

I have come to the conclusion that academia is nothing but intellectual masturbation. I have never seen people who are as full of them selves as academics. They espouse unnecessarily complex theories and procedures for the sole reason of making non-academics look starstruck when dazzled by their supposed brilliance. I'm currently reading part of a PhD thesis on software engineering, and the things that are suggested in this case might be applicable to 1% of development processes, and only in the case where one would be dealing with completely new concepts in computer science.
There are several more or less formal ways of developing software. Some are better than others, but what they all have in common is that they are extremely convoluted, and they requires books upon books to explain what is small sub-part of the entire methodology. It's not unheard of to have 900 page books on "realizing part A and part B of our amazing 59 part model".
Maybe I'm taking the carpentry approach to software development here, but please people it's not as difficult as you make it out to be. Granted, writing good software is not necessarily simple, but coming up with a methodology on how to handle everything around the actual writing of the source code is not as hard as people would have you believe.
The problem, I think, is that people are payed by the letter to write books on methodologies. I don't doubt that we need some research in the field, but to be quite frank, methodologies for developing things are, just like design patterns, revealed almost automatically after having worked in the industry for some time. What then happens is that academics come along and they look at these methodologies that have evolved in companies over time, working in this field, and they lump a bunch of them together, and try to extract some common features of successful methodologies. So far so good, to some extent, but what they then do is add their own rationale for these concept, and then they proceed to add their own parts to the methodology, to add their personal touch. The long-term goal of this is to get name recognition for something. Now, I know that having a good reputation is something we all want, but there are good and bad ways of going about it.
I can't say anything about any other fields of study, since I have just been in the academic world of software development, but I think that most academic research on methodologies, i.e. the meta-layer about getting work done, is pure intellectual masturbation, and it encumbers the whole software development profession with things that might otherwise have become clear, using nothing but common sense and experience.
It's fine when teachers teach students about some well-known methodology that is well rooted in reality. This way the students can have a head start when they get out in business life (which is the whole point of going to school). However, when teachers think "hey, I have a personal opinion of this little thing which I consider a flaw in a methodology, so I'm throwing all other information out the window and I'm creating my own methodology and then I'm teaching that to my students". This is wrong. I'm all for teaching students as much as possible, but we need to keep our eye on the ball here. Consolidate knowledge and look for things that are actually common between methodologies and teach people that. We don't need 10 methods that kinda-sorta work, we need 2-3 that actually work, all the time.
I guess academia is about finding new things and doing research info areas where business can't afford to go, or haven't thought off, but that doesn't give academia a license to go on some wild goose chase. When it comes to problems like some new algorithm, or finding a new element for the periodic table, or figuring out how to synthesize some new drug, I'm all for that. What I don't like is the meta-reasoning about all these things. At some point the reasoning about the reasoning about the reasoning of something has to stop. How many meta layers can we have before it all turns in to philosophy?

I want more concreteness in the things that are taught to students. Let students feel that the time spent in the class room actually gives them something of value, and not just something that they might be able to use should they go down a certain path of research in academia. Again, this is very much a carpenters approach to school, but isn't that what engineering is supposed to be about? I realize software is a young field, compared to building bridges or doing mathematics, but I also know that the rate at which the field develops is much faster than the speed seen for other fields in the past.

I'm rambling, but in summary, less intellectual masturbation in academia (at least regarding what is actually taught to students), and more concrete and correct knowledge.
Feel free to challenge me on this opinion.

Software is NOT an Engineering Discipline

I've had my fair share of software engineering courses, and what all my teachers keep telling me is that software is lagging behind other engineering disciplines in rigorousness and formality.
The problem, of course, is that software engineering is not an engineering discipline!
The most obvious point to this is that if software has some problem, it can be fixed after the fact. If a bridge has a problem you had better fix it before production starts. Same thing with building houses. You can't build something like Burj Dubai just to realize after a while that every other floor has no plumbing installed.
Another point is that you never have rigorous requirements when you build software. When you build a bridge, you know that it has to extend from point A to B, has to carry such-and-such a load etc, etc. With software, even the clients that know exactly what they want (which is to say, almost none), can't possibly come up with as exact a specification for what they want as someone commissioning a bridge or a house or a car.
People everywhere are trying to come up with different ways and methodologies for more exact specifications for software. Various modelling disciplines are showing up, but all they have to show for it is sporadic book sales. When you look at software projects as a whole, they are impossible to strictly specify. Some individual parts, like some protocol entity or some database interface, are possible to specify in a strict way, but they are still very much black boxes.
The fact that software can become so complex and so dynamic makes it impossible to include among the ranks of other engineering disciplines. In all other forms of engineering, you're bound by these lovely things called the laws of physics. In computer science, you are bound by only one thing, and that is execution time. If something isn't supported on the platform you are using, you simple emulate it. I'd love to have a device that could produce energy from nothing, but that goes against the laws of physics. In computer science, however, you would just create what you wanted. Like previously mentioned, the only thing that restricts what you can do in computer science is the time it would take for the computer to finish the task.

People can keep telling themselves and their students what they want, but I don't think I will ever be convinced that software deserves the prestigious "engineering" prefix.

EDITED TO ADD: Apparently I'm not alone in my opinion. (You really should read those links, especially the first one.)