Specifically what are some examples of where ideas of the masses where just wrong. Why did people latch onto the ideas in the first place? And why were the ideas dismissed? Or perhaps the ideas are still alive and well and if so why?

For example I might describe CORBA (and other similar technologies) as something that attempted solve the problem of communication between components of software. Many felt it was necessary to define contracts between various components. Ultimately, HTTP + JSON solved the problem for the masses and other various RPC mechanisms such as Thrift and Proto-bufs have popped up.

  • 1
    look at EXXXXXXXXXXXXXXXXXTREEEEEEEEEEEEEMEE Programming... – crasic Aug 9 '11 at 7:44
  • There are no "ideas of the masses", just ideas that become popular, and I don't think any idea about how to do something that is in use long enough to become mass-popular can be "just wrong", as it obviously must solve some problems or it would be abandoned immediately by everyone who tries it. – Michael Borgwardt Aug 9 '11 at 8:46
  • 2
    CORBA is no failure.. it's still in use – oenone Aug 9 '11 at 9:14
  • @oenone, it is a failure in the sense that it did not deliver on its original promise of solving interoperability problems in general, and it is now a niche technology. – Péter Török Aug 9 '11 at 9:38
  • HTTP JSON solved the issues with WebServices but not really with the other area of Softwares! – sarat Aug 9 '11 at 10:11

Basically, just as in the world outside computers, ideas and technologies compete for attention, leverage etc. Some win, some lose; and some may seem to be The Winner for some time, then fade into obscurity with the advent of The Next Big Thing. It may or may not have anything to do with which was actually the better. Witness VHS vs Betamax, or the more recent war between the various DVD formats.

CORBA was huge, awkward and hard to use, but it was the best some people could invent at the time (note that it was designed before the World Wide Web - and HTTP, Java, XML, ... - became widely known). And it was also a classic example of design by committee, where they cram in every idea to satisfy everyone, in the end making it uselessly bloated (at least viewed by today's eyes). Not to mention its price, which with the advent of FOSS soon became prohibitive.

Ultimately, HTTP + JSON solved the problem for the masses

At least for someone who hasn't seen a couple of similar "final solutions" rise and ultimately fall... It is good to keep in mind that there was a similar sentiment about CORBA in its time ;-)

I feel it is apt to quote from The Rise and Fall of CORBA:

CORBA’s history is one that the computing industry has seen many times, and it seems likely that current middleware efforts, specifically Web services, will reenact a similar history. [...]

Overall, the OMG’s technology adoption process must be seen as the core reason for CORBA’s decline. The process encourages design by committee and political maneuvering to the point where it is difficult to achieve technical mediocrity, let alone technical excellence. Moreover, the addition of disjointed features leads to a gradual erosion of the architectural vision. [...]

A democratic process such as the OMG’s is uniquely ill-suited for creating good software. Despite the known procedural problems, however, the industry prefers to rely on large consortia to produce technology. Web services, the current silver bullet of middleware, uses a process much like the OMG’s and, by many accounts, also suffers from infighting, fragmentation, lack of architectural coherence, design by committee, and feature bloat. It seems inevitable that Web services will enact a history quite similar to CORBA’s.

Now from a different angle: upon reading your term "ideas of the masses", I thought about very different things than CORBA or other standards; these are typically the idea of one person or a small group. I thought about notorious practices/points of views such as "cowboy coding", "code and pray", "it works on my machine" etc. These are IMHO real "ideas of the masses", as this is the way almost any beginner developer instinctively starts to write code. And they are wrong, as they don't scale neither in space nor in time - one can't create large, maintainable, extendable programs this way. Yet I feel that unfortunately it is still the norm rather than the exception for people to try to work this way in professional shops all over the world.

The other extreme of this is many managers' and theorists' ideas of the "right approach" to SW development, manifesting in big-M Methodologies like CMM, RUP, Waterfall etc. The idea lying behind all of these is that all you need is the Right Process, and it will start to automatically produce quality software in a deterministic manner, regardless of who the developers actually are. Notice that the same game can be played using Agile methods too - it's just a change of labels. Any manager who believes that selecting (and keeping) the right members for his/her development team is less important than the development process, is bound to fail, whichever that process happens to be. However, this belief in Process still seems to be prevalent - maybe it is still taught in management schools?

  • Reading through that link: dear god, CORBA must have been horrible if V1 EJBs supplanted it because they were simpler... – Michael Borgwardt Aug 9 '11 at 8:50
  • The product Michi Henning went on to develop rectifies a lot of CORBA's deficiencies. – Blrfl Aug 9 '11 at 10:41

A frequent example of people gone wrong is the waterfall model. This is a diagram of the stereotypical waterfall model, which also appears in Winston Royce's paper "Managing the Development of Large Software Systems".

Winston Royce's Waterfall Model

This image is followed by this text:

I believe in this concept, but the implementation described above is risky and invites failure...The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output, transfers, etc., are experiences as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance. Yet if these phenomena fail to satisfy the various external constraints, then invariable a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.

Later in the paper, Royce presents alternative process models that involve iterating between the current phase and the previous phase and a cycle between requirements-analysis-design and another cycle between design-code-test. He also identifies a number of documents and during which phases they should be completed, and advocates customer involvement and multiple waterfalls within each phase to include analysis, testing, and usage of all artifacts involved. In all actuality, what Royce discusses might be considered an early approach to agile methods - still very much plan-driven, though, but a basis for the agile movement.

Why people latched on to the very first waterfall, I don't know. I guess they like taking on risks and inviting failure.

  • 6
    People latched onto the first Waterfall method because this would be strikingly similar to how a civil engineering project like building a 40 story skyscraper would be. When building a skyscraper the requirements and constraints are too painfully clear to miss and nothing major will change half way through. Analysis and design (architecture) must be complete and thorough leaving no room for interpretation. The building must be built to spec and finally the inspectors must come in and qualify the finished product. Software almost never is this clear thus why the Waterfall model is a failure. – maple_shaft Aug 9 '11 at 11:04
  • 2
    @maple_shaft I find that interesting, since Winston Royce was the first person to discuss using this model on a software project and create the diagram that is familiar to everyone today, however people didn't keep reading to see why he said it shouldn't be used on a software project. If the person who first writes the idea says it's a bad one and states not only why, but how to do it right, why would people choose to latch onto it anyway? I wonder if it has to do with the first software engineers coming from mathematics and electrical engineering backgrounds. In EE, does this approach work? – Thomas Owens Aug 9 '11 at 11:28
  • 1
    The waterfall model isn't entirely wrong: It correctly identifies the general phases in developing a software project and orders them logically. What it fails to acknowledge is the fact that a software project can be written iteratively and modularly, and as such, the steps the waterfall model describes can be performed in various configurations for individual iterations and / or components of the whole system. – tdammers Aug 9 '11 at 11:29
  • 3
    @Thomas Owens, "If the person who first writes the idea says it's a bad one and states not only why, but how to do it right, why would people choose to latch onto it anyway?" Adam Smith the father of modern Capitalism wrote his manifesto on the free and pure market, but then later in his book goes on to talk of how dangerous the concept of corporations can be and how they subvert governments to influence markets in their favor. Conveniently people ignore the parts of a concept that they either don't understand or go against their pre-conceived notions of what is correct. – maple_shaft Aug 9 '11 at 12:14
  • 2
    "Why people latched on to the very first waterfall, I don't know. I guess they like taking on risks and inviting failure." IMHO it's exactly the opposite. People in general like to feel they are in control of the situation, and process diagrams and elaborate methodologies give them that sense of security. Since those processes and charts have helped them before in a lot of other areas, they assume (wrongly in this case) that it will work out the same way in SW development too... – Péter Török Aug 9 '11 at 14:52

Automatic generation of code from a higher abstraction level, or automatic programming.

The Wikipedia article is somewhat lacking in historical information, but this has been a dream of managers ever since programmers became more expensive than computers.

After the development of higher level languages like Fortran and Cobol, came the development of languages for special domains like report writing. Easytrieve and SAS were a couple of examples.

During the 1980's CASE tools were the rage. CASE stands for computer-aided software engineering. It was thought that the rigorous application of engineering principles would make software development faster. The main reason these tools didn't catch on, besides the expense, was the high level of data standardization required for the tools to work effectively.

The Internet came into prominence in the 1990's. The types of programming that the Internet facilitated exploded. Programmers were required to handle illustrations, maps, photographs, and other images, plus simple animation, at a rate never before seen, with few well-known methods. The number of technologies to produce these objects multiplied. Dreams of automatic programming faded.

Outsourcing programming to cheaper locations is one of the few methods remaining to reduce programmer costs. The problems with outsourcing include communication problems and specification problems.

  • 1
    Also, SQL and Visual Basic, both of which were advertised to allow non-programmers to write programs. – Sean McMillan Aug 9 '11 at 17:29

Formal Methods

Once upon a time, it was proposed that software could be proven correct. (The idea being that testing can't show that there are no errors, but proofs would be able to.) Unfortunately, devising a proof for a program has some major drawbacks:

  • It is more difficult and time consuming than writing the program.
  • It has to cover the whole program, meaning you need proofs for any library, OS, etc...
  • It doesn't prove the absence of bugs, since those bugs may be cause by accident.

This concept was very popular in the 70s.

Linkage: http://en.wikipedia.org/wiki/Formal_methods http://c2.com/cgi/wiki?ProofOfCorrectness http://c2.com/cgi/wiki?PractitionersRejectFormalMethods

  • 3
    There's more to formal methods than just proofs. It ranges from the heavily mathematical and use theorem provers that you mention to more lightweight methods that involve modeling using UML and OCL and creating a formal specification in Z. Yes, introducing any level of formal methods adds time and cost, but if you are building software that's in something that could kill or injure people (ranging from a pacemaker to an aircraft to a missile), spending the extra time and effort to verify and validate as much as possible could mean the difference between life and death. – Thomas Owens Aug 9 '11 at 13:10
  • @Thomas: A good point. And formal methods do have some adoption in projects where death is on the line. But they certainly weren't the silver bullet for bug-free software. – Sean McMillan Aug 9 '11 at 14:33
  • Absolutely. They have their place in mission and life critical software, to varying degrees depending on the system. After all, there are no silver bullets. – Thomas Owens Aug 9 '11 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.