Most overhyped software engineering technologies of the last 20 years(programmers.stackexchange.com)
programmers.stackexchange.com
Most overhyped software engineering technologies of the last 20 years
http://programmers.stackexchange.com/questions/38505/most-overhyped-software-engineering-technologies-and-concepts-of-the-last-20-year
11 comments
Cloud Computing - A term, like "world peace", "think outside the box", or "hooking up", that means everything and nothing at the same time.
Fourth General Languages (4GLs) - Technology to enable non-programmers to claim that they are programmers.
eXtensible Mark-up Language (XML) - Primary data, along with secondary data needed to describe the primary data, all in one file, that a receiving program could act upon, as long as it knew what the secondary data meant.
Unified Modeling Language (UML) - Technology needed to add another layer of personnel to enterprise IT: people smart enough to draw but not smart enough to program.
Agile Software Development - A new name for what the fittest have used to survive for 50 years.
NoSQL - The Y2K of the 21st century, without the hard deadline. Everything will die, but no one can say why.
Object-Oriented Programming (OOP) - A technology invented to make associates of Big 5 consulting firms who didn't know what they were doing appear as if they did.
Test Driven Development (TDD) - A fancy term given to tried and true methods just discovered by hipsters whose code didn't work.
Rapid Application Development - Prototyping. But no respectible IT person would buy a book with the word "Prototyping" in the title, hence the new name.
Web Frameworks - More software added to perfectly adequate existing software used by programmers depending upon their level of experience, backlog, or masochism.
Hacker - Either (a) One who breaks into other systems, (b) one who builds stuff, (c) a programmer, or (d) a groupie of one of the above.
Fourth General Languages (4GLs) - Technology to enable non-programmers to claim that they are programmers.
eXtensible Mark-up Language (XML) - Primary data, along with secondary data needed to describe the primary data, all in one file, that a receiving program could act upon, as long as it knew what the secondary data meant.
Unified Modeling Language (UML) - Technology needed to add another layer of personnel to enterprise IT: people smart enough to draw but not smart enough to program.
Agile Software Development - A new name for what the fittest have used to survive for 50 years.
NoSQL - The Y2K of the 21st century, without the hard deadline. Everything will die, but no one can say why.
Object-Oriented Programming (OOP) - A technology invented to make associates of Big 5 consulting firms who didn't know what they were doing appear as if they did.
Test Driven Development (TDD) - A fancy term given to tried and true methods just discovered by hipsters whose code didn't work.
Rapid Application Development - Prototyping. But no respectible IT person would buy a book with the word "Prototyping" in the title, hence the new name.
Web Frameworks - More software added to perfectly adequate existing software used by programmers depending upon their level of experience, backlog, or masochism.
Hacker - Either (a) One who breaks into other systems, (b) one who builds stuff, (c) a programmer, or (d) a groupie of one of the above.
SOAP - Remote procedure calls (maybe) that use web frameworks and XML when I all really wanted was to know the latest user setting.
CORBA - Remote procedure calls (maybe) for object-oriented programmers who can't agree which language to use, but are expected to agree on how to represent it.
Design Patterns - What to use when your language isn't up for the task.
CORBA - Remote procedure calls (maybe) for object-oriented programmers who can't agree which language to use, but are expected to agree on how to represent it.
Design Patterns - What to use when your language isn't up for the task.
I feel your text for TDD and Agile is the same used to hype the terms by the proponents.
I've found that people tell me "You're not thinking outside the box" when they want me to accept something fundamentally untenable.
Tell them they're in the "outside the box" box[1]?
[1] http://lesswrong.com/lw/k6/the_outside_the_box_box/
[1] http://lesswrong.com/lw/k6/the_outside_the_box_box/
I did not see "DSL" in your list.
I think the whole premise of this question is kind of... off. Just about every tool goes through a period of being hyped. That's why we use them. Show me a tool that hasn't been hyped and I'll show you a tool that not enough people know about.
Complaints that things are "overhyped" are dubious. Everything is overhyped to some degree. What would an "optimal" amount of hype be, and how would you regulate it? If you underhype your product, you are leaving profit on the table. To maximize the number of satisfied customers, you must ultimately run your product past many, many people who ultimately won't be satisfied customers.
Meanwhile, I can't help but fear that this poll is just another measurement of popular fashion: Once a technology has found its niche, can we really judge its ultimate importance without being experts in the niche? We can all tell when something becomes unfashionable, but it's quite hard to know just what its ongoing impact really is. Unfashionable technologies fade into the woodwork, but they do vital work nonetheless. Was COBOL overhyped? Was Perl overhyped? Can I really claim that XML was overhyped, even as I type words into a machine built largely out of XML-based config files? When I pound the table and declare that, say, Java was overhyped, am I really saying more about myself than I am about Java? I have a vision of myself, walking around the room while using my iPhone to compose a message claiming that tablet computers and robots are overhyped, and then tripping over my Roomba.
Complaints that things are "overhyped" are dubious. Everything is overhyped to some degree. What would an "optimal" amount of hype be, and how would you regulate it? If you underhype your product, you are leaving profit on the table. To maximize the number of satisfied customers, you must ultimately run your product past many, many people who ultimately won't be satisfied customers.
Meanwhile, I can't help but fear that this poll is just another measurement of popular fashion: Once a technology has found its niche, can we really judge its ultimate importance without being experts in the niche? We can all tell when something becomes unfashionable, but it's quite hard to know just what its ongoing impact really is. Unfashionable technologies fade into the woodwork, but they do vital work nonetheless. Was COBOL overhyped? Was Perl overhyped? Can I really claim that XML was overhyped, even as I type words into a machine built largely out of XML-based config files? When I pound the table and declare that, say, Java was overhyped, am I really saying more about myself than I am about Java? I have a vision of myself, walking around the room while using my iPhone to compose a message claiming that tablet computers and robots are overhyped, and then tripping over my Roomba.
"Over-hyped" is over-hyped.
One of the best things about being a math major instead of a CS major is that it gives you a sense of history and how small the Next Big Thing probably is. One of the weird things about computer science and tech to me is that practitioners don't know what happened in 1980s, much less the theory that was developed over the last 150 years.
I would say that Boolean Algebra was actually an important advance, or the Fortran compiler (early 1960s), or a working system based on relational algebra (late 1970s). But proponents of XML/ Java/ Patterns/ Functional Programming/ Language XYZ/ NoSQL/ blah/ blah/ blah make it sound like their pet technology is a revolution, when it is usually an incremental change on tech/ theory that is very old.
And when it is an incremental change driven by corporate funded standards committees, you know it is going to be a complete cluster f*ck that is forced on the entire world by stupid IT managers with business degrees.
I would say that Boolean Algebra was actually an important advance, or the Fortran compiler (early 1960s), or a working system based on relational algebra (late 1970s). But proponents of XML/ Java/ Patterns/ Functional Programming/ Language XYZ/ NoSQL/ blah/ blah/ blah make it sound like their pet technology is a revolution, when it is usually an incremental change on tech/ theory that is very old.
And when it is an incremental change driven by corporate funded standards committees, you know it is going to be a complete cluster f*ck that is forced on the entire world by stupid IT managers with business degrees.
At least some aspects of NoSQL are novel from an algorithmic perspective, so it's unfair to dismiss it as a buzzword. The underlying gossiping protocols that enable no single point of failure are fairly recent developments (Chord is a recentish gossiping algorithm if I remember correctly). Just think about writing a distributed database system without any designated master/control nodes-- all kinds of fun algorithmic problems will pop out: randomized algorithms, random graphs, distributed indices, decentralized search, ...
The problem is that the underlying distributed algorithms are not exclusively the domain of NoSQL systems and, likewise, one could easily use SQL with a key-value store, provided that one had access to a schema with which to resolve objects and their identifiers. Developers have been using non-relational data stores with SQL-based front ends for years.
I agree with UML and CASE tools, it was always a time-waster that produce too many things and never used.
But I disagree with XML and OOP. XML was necessary for the first web APIs we had (they were called SOAP, in case you wasn't a developer that time). And OOP is everything you do, it's a way to write code more clear and maintainable (just forget everything about the 'reuse your code' and 'speed you development', OOP isn't just about this).
But I disagree with XML and OOP. XML was necessary for the first web APIs we had (they were called SOAP, in case you wasn't a developer that time). And OOP is everything you do, it's a way to write code more clear and maintainable (just forget everything about the 'reuse your code' and 'speed you development', OOP isn't just about this).
OOP is everything you do
OOP may be everything _you_ do, but it is not everything I do, and there are large vibrant software development communities using paradigms and tools that are not particularly object-oriented. Beware of making over-generalizations like this.
OOP may be everything _you_ do, but it is not everything I do, and there are large vibrant software development communities using paradigms and tools that are not particularly object-oriented. Beware of making over-generalizations like this.
"XML was necessary for the first web APIs we had"
People were building systems that had APIs exposed via HTTP a long time before XML.
People were building systems that had APIs exposed via HTTP a long time before XML.
And what's so special about HTTP? Communicating over the network is old - things like RPC have been around for a long time (first spec in 1976, according to Wikipedia.)
That statement isn't strictly true as raganwald pointed out but it's also too broad: the current OOP item makes a far more defensible position: "...in the sense that we are still writing lots of new OO code instead of just plugging together reusable objects to design new systems". Using OOP to cleanly contain related code and data is far more defensible than the decades of claims that programmers would just plug things together like lego bricks, which is finally dying out but has left behind a wasteland of overly-ambitious projects which will never be used by more than one project but all carry the burden of trying to be as general as Java.
"Over-hyped" doesn't mean the technology doesn't have merit. Both XML and OOP have great merit but were very much over-hyped for years as being always applicable and the ultimate answer for everything.
There were some fanciful things said in the past 15 years about both of these and others. Articles in Wired with apparently smart people bubbling with enthusiasm for the limitless potential. Even at the time I thought, fer gosh sakes, XML is an encoding. The really hard problems are still unsolved.
I still hear "we'll use XML" instead of concrete architectural plans, like it's a magic wand you wave over your project and all your dreams come true.
There were some fanciful things said in the past 15 years about both of these and others. Articles in Wired with apparently smart people bubbling with enthusiasm for the limitless potential. Even at the time I thought, fer gosh sakes, XML is an encoding. The really hard problems are still unsolved.
I still hear "we'll use XML" instead of concrete architectural plans, like it's a magic wand you wave over your project and all your dreams come true.
UML diagrams have one redeeming quality: when they allow direct full-code generation. I always saw jaws dropping when demoing ArchGenXML for making Plone products.
Some of the stupidest code I've ever seen was auto-generated from UML. People get all excited by seeing code generated from a picture and forget to check if the code produced is actually sensible or not - in most cases I've seen the code produced is abominable.
That's what I liked with ArchGenXML. The code is quite good.
At least as good as code for Plone components can be. I heard it has improved a lot since I left Plone-land, but, when I worked with it, there was a required level of confusion in your code for it to work with all layers of Zope and Plone.
I assume UML diagrams can render very clean code for Django and Zope 3.
At least as good as code for Plone components can be. I heard it has improved a lot since I left Plone-land, but, when I worked with it, there was a required level of confusion in your code for it to work with all layers of Zope and Plone.
I assume UML diagrams can render very clean code for Django and Zope 3.
Before SOAP we had... XML-RPC. And before that other ways (albeit not as formalized) for over-network communication. XML did bring some ease of cross-platform exchange to the scene, no doubt, but don't give SOAP too much credit. :/
Hmmmm.
There is a difference between over-hyped and having a bitch-fest about things your boss thought was cool. Very sorry you had to do too much UML on that last project but it works very well for what it is: a universal way of diagramming parts of computer systems for purposes of communicating about them. Probably not so good as a universal spec system, or a runnable model, or any one of the 17 other things folks thought they could do with it. Same goes for a lot of this other stuff. We confuse the environment around a tool or technology with the tech itself.
Everything is overhyped. We're like that: we want magic bullets to fix all of our problems. Everything is over-applied and over-promised.
The more I think about it, the more this is a really bad, perhaps trollish, question. It does nothing to increase people's understanding, and only serves to have a place to gripe and complain. Nothing wrong with griping or complaining! As long as we all realize how subjective it is. This question assumes that there is some objective standard for being over-hyped. I don't think that premise is true. You end up with a bunch of people arguing over whether chocolate ice cream tastes good or not.
There is a difference between over-hyped and having a bitch-fest about things your boss thought was cool. Very sorry you had to do too much UML on that last project but it works very well for what it is: a universal way of diagramming parts of computer systems for purposes of communicating about them. Probably not so good as a universal spec system, or a runnable model, or any one of the 17 other things folks thought they could do with it. Same goes for a lot of this other stuff. We confuse the environment around a tool or technology with the tech itself.
Everything is overhyped. We're like that: we want magic bullets to fix all of our problems. Everything is over-applied and over-promised.
The more I think about it, the more this is a really bad, perhaps trollish, question. It does nothing to increase people's understanding, and only serves to have a place to gripe and complain. Nothing wrong with griping or complaining! As long as we all realize how subjective it is. This question assumes that there is some objective standard for being over-hyped. I don't think that premise is true. You end up with a bunch of people arguing over whether chocolate ice cream tastes good or not.
I think the way people are responding isn't helping this question. This could have been good if responders had elaborated on what was promised vs what was delivered, but instead they just list the technology and write, essentially, "this was overhyped".
"Enterprise" anything. Call it what it almost always is: Glue.
One of the few truly enterprise developments has been environmental virtualization. And it's been going on longer than most people realize.
EDIT: Perhaps this should be disqualified as a buzzword. But too often, it's treated -- if ignorantly -- as "a technology".
One of the few truly enterprise developments has been environmental virtualization. And it's been going on longer than most people realize.
EDIT: Perhaps this should be disqualified as a buzzword. But too often, it's treated -- if ignorantly -- as "a technology".
I'm surprised VRML wasn't listed; I remember when VRML was supposed to be the future. It was the original web 2.0.
I remember the VRML hype, but I think it differs strongly from web 2.0 in that everyone agrees that web 2.0 is actually implemented in production lots of places (we just all disagree on what exactly it consists of).
Some of these are not software engineering technologies at all: virtual reality, network computers... SharePoint?
Smalltalk is now a "visual" language...
And, BTW, VB.NET is, according to Wikipedia, the only language about 60% of the .NET programmers use.
And, BTW, VB.NET is, according to Wikipedia, the only language about 60% of the .NET programmers use.
Having the word "visual" in the name doesn't make it visual.
Right. To be truly visual a language must also provide a bunch of widgets that you drag and drop to build graphical user interfaces. Oh wait...
A text-based language with a GUI designer tool = a text-based language plus a GUI designer tool. It doesn't = a visual language.
I guess MSFT did take a stab at something closer to an actual visual language in Visual Studio, in the form of the Workflow Foundation designer.
I guess MSFT did take a stab at something closer to an actual visual language in Visual Studio, in the form of the Workflow Foundation designer.
I admit Visual Basic is not near as cool as say Scratch, but it is pretty visual, especially when compared to BASIC. I think it was fair for Microsoft to use the term, some 20 years ago, given that visual languages at that time were called dataflow languages. Now, had they called it Dataflow Basic, I would have been pissed.
java?
I was taking a master's level database course at the time of XML mania and we spent a massive amount of time on XML because the prof felt XML + XQuery was going to displace traditional relational databases. There were numerous reasons why this didn't happen, but a not insignificant number of people bought into it. Some database-y things are possible with XML, but you'd be crazy to replace a massive schema with it without good reason.
OOP is another great one. It is incredibly useful to write OOP code. However, the promise at the beginning of the OOP mania was that you could "snap code together as easily as Legos... even normal people will be able to write complex software!". OOP has certainly helped make code more maintainable and fostered a lot of code re-use, but the ease described by the early hype was hugely off the mark. It turns out it's really hard to write super-reusable code such that you can use it "as-is" in situations the original authors never envisioned.