The examples of alleged "stuffups" given here are only allegations - there is no evidence given, or links to anywhere we could find such evidence. I could just as easily claim that the Apollo space program was delayed for 3 decades due to continued software failures, or the Sydney Opera House had bad accoustics for the first 10 years of its life due to software failures... I remember a rumour about this one, but what's the point of sensational allegations without being able to verify it - thats the way the tabloid media works, but not an encyclopedia. Graham Chapman
Oh great, another kook to deal with. The article you removed is pretty sloppy, but what you replaced it with was nothing but a personal screed that the whole field is nonsense. Well it may well be, but it is a respected field of study that deserves to be covered in an encyclopedia along the lines of those who study it and write about it. The fact that you are not alone in claiming that the field of study has been largely unsuccessful is something that ought to be covered, but that in no way invalidates the field of study itself, its definitions, its goals, or its methods. It merely reflects that the field itself is still in its infancy.
There are lots of programmers here, as you might suspect with any net-based group. I've been programming since 1979, and professionally since 1982, so I think over 20 years in the business qualifies me to say that your opinions here are not mainstream. Software engineering methods outside of mere computer programming are discussed and used in every serious software enterprise, and are taken seriously by most. -- Lee Daniel Crocker
"respected" by who?
I used to believe in this field. But note the incredible bias of its typical practitioners: total failure "in no way invalidates the field of study itself, its definitions, its goals, or its methods. It merely reflects that the field itself is still in its infancy." This is like the dudes still looking for the particle in the accelerator that will a GUT suddenly appear.
They never acknowledge the probability that their whole field is built on a set of wrong premises. In this case, that "software engineering" is just "requirements engineering" with less accountability, more jargon, and absolute disconnection between the bodies of real people affected by actions of real users. Thankfully, this point of view is in decline. Most of us today would accept that a perfectly "engineered" video game showing how to turn ordinary household implements into weapons of mass destruction would be well within their paradigm, and the definitions, goals and methods that they use, but also would accept that it would be unlikely to be allowed to reach beyond such an "infancy" for various legitimate ethical and social reasons.
Any attempt to actually "engineer" software soon discovers that without the body references implied by the real fields of engineering (e.g. chemical, mechanical, electrical) there is no way to assess safety or closure problems. Accordingly, the "field of study itself, its definitions, its goals, or its methods" is invalid ethically, invalid ontologically, and invalid bodily.
So, my position is that software engineering does not exist, cannot exist, is a marketing term for a marketing concept, and to those who believed in it, is a stupid attempt to impose simple models on complex processes. It is just as absurd to talk about "requirements engineering" in any other field of design. This entire characterization of the process of creating complex tools or instruments has been discredited thoroughly, along with the SEI CMM that helped spawn it. There is no value whatsoever in the term or concept of "software engineering" excpet insofar as software is part of other, more operationally bound, forms of engineering. One might as well call the field "persuading the paying client that certain of his requirements do not exist", i.e. marketing.
The reader is far far better off learning how to distinguish an ontological distinction from an operational distinction from an "ordinary" distinction, which will drastically aid their listening and understanding. Also to have a general notion of risk and of philosophy of action so that they do not make the mistake of assuming that actions carry uniform risk to the user or their surroundings. If we intend to introduce the rudiments of software design here, as we have started to do in object-oriented programming, then we should employ those terms as much as we can, e.g. problem domain analysis, legacy domain analysis, solution domain analysis. We should certainly be sure to outline schema and ontology as applied to the process of laying out a software design itself.
But under no circumstances should we pretend that software "risk" or "benefit" can be assessed outside of a foundation ontologyorpolitical economy.
The idea that software could be engineered to better and better meet user "requirements" until it became inseparable from their daily lives has been thoroughly discredited. First by the sloughing-off by coders and users of all products of more disciplined processes, then by the failure of OOP to produce any "reusable components" outside the political standards process, then by the "dotcom boom" and the pending collapse of Microsoft once honest stock option accounting is in place.
Personally, I think that the day that this Windows Religion collapses, to be replaced by many fragmented subsystems, and the day that the Web Religion collapses, it will be relatively clear that the so-called "engineering" was simply bending human belief systems to fit what the systems could do at the time. That no "engineering" in the sense of taking state of the art science and turning it into practical or useful tools was occurring. That the entire process is much more viral and organic and more like gardening.
And, likely, that the control subsystems and highly constrained simulations, e.g. of hardware that track its states in a device driver, will not be seen as any kind of "engineering", but rather, as Dykstra put it, "computer science" proper - creating mathematical models to closely model the real world.
It might also be seen, like economics, as a sub-branch of general systems theoryorphilosophy of action. But I wouldn't hold my breath. More liely the terms "software engineering" and "requirements engineering" will die a well-deserved death together.
Here's the paragraph about the Australian failures. Some of these might be good examples, but they're certainly not as well known and central to the field as the ones mentioned, and I don't know whether they led to advancements in the field or if they are good examples of failure of specific methodologies that would merit including them. More info is needed about them; a merelist of screweps doesn't make a good article. --LDC
Other big stuffups I know about, though they were from the 80's and 90's and they're all Australian:
"In very recent developments (as of April 2002) apparently Texas is considering issuing the PE license for software engineers while California is considering outlawing the use of the term Software Engineer as a noun or field of employment."
