 | This is an archive of past discussions about Software engineering. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
| Archive 1 | Archive 2 | Archive 3 | → | Archive 5 |
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
64.174.7.xxx
The bias is obvious! The article assumes that software can be engineered and is written from the perspective of a software engineer wannabe. There is some babble about complex project failures and the assumptions that the coining the phrase "software engineer" will save the day.
It is now 2002 and all the complex software failures cited from the 60s and 70s, have been superceded by much vaster fiascos. Even accounting for the fact that most of the most complex projects are black programs operated by the U.S.G. and the failures which exist until some artist delivered a perceived solution to newly bald project managers desperately grasping at straws .... the commercial failures have been on a new modern scale as well. See the Denver Airport fiasco and read the glowing articles about "software engineering" right up to admitting they were late and that it would not work well if at all ever.
Perhaps Salon.com carries some back issues? I cannot believe that "Salon.com" citing this heavily non NPOV article which contains no sop to the future software artists and/or hackers who may encounter this article is viewed as a good thing. Does salon set the standard of expectation of balanced treatment of engineering articles at this institution or does our own published NPOV?
Maybe we can wikify this article to some form of usefulness but the overall underlying bias makes me think it is more effective to refactor it a piece at a time, perhaps after some professional programmers show up to help out, assuming they choose to stick around after a link from software or software programming or software hacking or coding or hacking leads them to this policy non compliant dreck ..... worse! Future programmers that I may be working with may read this useless shit and be impaired on my future projects! This is disaster. I go now to help correct or delete some of these existing links until we can perfect this trash. user:mirwin
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
- So this might perhaps qualify you to come up with a list of these methods along with some explanations. The article as a whole needs more attention. --Hirzel 09:21 15 Jun 2003 (UTC)
Moved from discussion of the material and perspective of the presentation to personal attack in record time. No offense mate, if you wrote the original dreck, anyone can have an off day.
Layman and practioners take many things seriously. Do you personally know any "Software Engineer, PE"? The term professional engineer in the U.S. refers to one licensed to certify that a engineering specification is adequate to protect the public safety and interest.
Perhaps we have a cultural deviation here, where do you reside and do you percieve the definition of "engineer" different there than from the U.S.
I am familiar with the SEI. They do a lot of good work but they are clearly advocates with a vested interest. Certainly references to them belong in the material presented per NPOV from the view of a practitioner or fan of "software engineering"
In the U.S. we have "Sanitation Engineers" who are more highly paid than garbage collecters. I am not aware of any states that license them as PEs yet but it may have happened somewhere in our 50 different cultures. user:mirwin
"respected" by whom?
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 ontology or political 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 theory or philosophy 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 1980s and 1990s and they're all Australian:
- The automatic tollway in Melbourne was delayed a year due to engineering difficulties, but even with the delay the software wasn't ready and they couldn't charge tolls for the first three months of operation.
- The automatic ticketing system for Melbourne's public transport was delayed for years because of software difficulties. (It is still hated, but that has more to do with hardware and politics rather than strictly software).
- The combat system for Australia's Collins-class submarines was so bad, it has had to be scrapped and replaced with an American system.
- The Jindalee Over-The-Horizon radar project was delayed for years because Telstra, who were contracted to do the programming work, couldn't get it right. They were eventually sacked and Rockwell was given the contract.
"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."
- my money's on California - Texas wants this for military industrial complex reasons, as there has traditionally been little consumer or industrial software produced there that isn't ultimately destined for military use - the different character of the two regions' software industries might well be the cause for the difference. Another view is that "Software engineer" is a military term, since only the military actually has a policy of uniform risk for all elements of a system, and can put a dollar price on a human users' life and admit it. 24