 | 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 4 | Archive 5 |
- Software engineering is already as predicatable and reliable as many fields of engineering, such as space or biological engineering. Although large, reliable software systems can be and have been constructed, software projects that fail during construction or in service are still too common. However, large traditional engineering systems also fail, such as Three Mile Island, Chernobyl, Bhopal, Space Shuttles Challenger and Columbia, are also too common.
There should be a reference/proof for the claim "Software engineering is already as predicatable and reliable as many fields of engineering". Without proof this sentence is a simple opinion and should be marked as such ("Some people claim..."). Also, it is debatable whether Chernobyl failed because of engineering problems. In space engineering many problems (and at least one desaster) were caused by software defects. MH 17:22, 17 Nov 2003 (UTC)
- Automobiles kill 40,000 people in the U.S. every single year. Automobiles and roads are engineered by automotive and civil engineers. Software has nothing that kills this many people. (There is a simple automotive fix to drastically cut the death rate: limit the top speed to 30 mph, which would be an easy engineering change. Compare this to GUIs being designed so that users cannot misuse them.)
- The space shuttle blew up because of bad O-rings, and bad foam insulation, which are engineered by mechanical and aerospace engineers. Software has nothing that is as bad. Okay, software blew up a few unmanned rockets, and sent a Russian landing capsule off course, but that is peanuts compared to the mechanical and aerospace problems. Mechanical and aerospace problems blew up many rockets and destroyed two manned space shuttles.
- If Chernobyl failed because of operator problems, then SEs can also argue that their software fails because of operator problems (users should just avoid the buggy parts and get training to know where the bugs are). Be fair in your comparisons.
- Software has many, many, many problems. But, at least SEs acknowledge our problems. All of the official reports about the space shuttle disasters point out that NASA engineers believe that they are perfect and have no problems to worry about, so they live in a state of denial. Traditional engineers have many, many, many problems, too.
- In some ways software engineers do things much better than traditional engineers. The rate that SEs create value by creating new features is tremendous. Compare the rate at which "safe" railroad couplings were added to the railway industry.
- I have often felt that aerospace engineers (most particularly) yell a lot about the failings of software, to turn attention away from their own failings. They use software as a scape goat. I know of only a few cases where software was implicated as the cause of a crash. Aerospace engineers caused all of the other crashes (exploding fuel tanks, worn out elevator screws, no stall prevention, and so on).
^ Why is that there? ^ - Please see Wikipedia:Talk page for guidance on the uses of talk pages. I can't see how the above is relevant to the development of this article. Angela 19:39, 20 Nov 2003 (UTC)
- The writer MH specifically mentions software causing problems for aerospace. Many of the authors prior to about Oct 2002 of this page emphasized the failings of software engineering, usually related to military or aerospace systems. The SEI is sponsored by the U.S. military and it created to CMM and CMMI as ways to "control" software development. There is clearly a long-term relationship between software and aerospace. But, you are correct.
- The aerospace desaster I was refering to was the Ariane 5 story. But you are right that this discussion is probably not fruitful. What I still think, however, is that the above claim "Software engineering already is..." is a broad , unspecific opinion which should be marked as such or be backed up by some (statistical, scientific) evidence. On this talk page some people are discussing what software engineering actually is. The claim above gives the impression that there is a consesus about that and that the process of building software is as well-understood as is building a bridge. MH 08:46, 24 Nov 2003 (UTC)
I removed the following paragraph as the claims are unreferenced. Is there a source for this? As far as I was aware, such interests are increasing. Also, see Wikipedia:NPOV - you shouldn't really be claiming something is interesting to note as that's just your point of view. Others may think it completely boring to note. ;) Angela 19:39, 20 Nov 2003 (UTC)
It is interesting to note that interest in quality is waning. The number of books and consultants talking about quality dropped by a factor of 3 from 1998 to 2003. Surveys have shown that quality is rarely the distinguishing factor in most markets. And certainly, quality cannot be considered independently of cost and value.
- Noted.
I removed the following paragraph, because it has nothing to do with the practice of software engineering: it's just a list of kinds of software. Ed Poor
- Software engineering applications include email, embedded software, graphical user interfaces, office suites, operating systems, optimizing compilers, relational databases, robotics controllers, video games, and the world wide web. Other important applications include accounting, airline reservations, avionics, banking, and telephony. These applications embody social and economic value, in that they make people more productive, improve their quality of life, and enable them to do things that would otherwise be impossible.
- I agree. List of software engineering topics is a better place for this. Angela 20:53, 20 Nov 2003 (UTC)
- I disagree. Many computer scientists (Dijkstra and Hamming come to mind) argued that software is not a tool for applications, but a tool for mathematics. Software engineers usually write particular kinds of applications, and I believe it is instructive to show the kinds of applications that software engineers do write. A counter example, is that "scientific simulations" are written by scientists: signal analysis from radio telescopes, simulations of heat transfer in the sun, and so on are NOT software engineering applications, they are scientific applications.
- You may know what kinds of software practitioners write. However the casual reader probably does not know. Is wikipedia a forum for experts to show what they know, or a forum for the non-experts to learn? BTW, consider myself a friend of hard-working SE practitioners and cute-and-fuzzy ones, so no login is needed.
- A previous commentator argued that there was no discussion of "humanity". This paragraph is the one place in the article where it is pointed out that software engineering is mostly applied on behalf of society.
Software engineering is all about productivity and quality. We could use monkeys to program machine code with toggles on the front panel of the computer, except that we want productivity and quality. That is what distinguishes software engineering from just a hobby.
^Again, this doesn't seem to be aimed at improving the article.
- The point is that there are many kinds of software. Software engineers emphasize some kinds, but not all kinds. Suggest that writing any kind of software makes one a software engineer demeans all software engineers. A feeble list of SE applications sheds a small amount of light on the subject.
- There are many skill levels of writing software. Hobbyists can write software using whatever approaches they want. But software engineering is a profession, where things like productivity and quality matter. In fact cost is one of the reason that software jobs are being exported to put SEs in the US out of work. Cost is a key component of both productivity and quality. Perhaps there should be a discussion of these issues.
- A second point is that while I believe that you know what software engineers do, I have been watching various newsgroup type exchanges (like at www.software-engineer.org) to see who wants to know about software engineers. Many of the questions are from high-school students, who are probably looking for something to tell a guidance councellor. I think that making the introduction to this article readable and understandable by a high-school student (who many not be aware of all the apps) is a good thing.
Ed Poor has made the following points: "I understand software engineering, as Bush might say: I /am/ one! ;-)" and "Moving an excellent list of "types of software" to talk for disposition) " and "(productivity and quality are not mentioned in the article, except in the first para, so I'm cuttin' 'em -- But people are important, so I'm a-puttin' 'em in.)"
Where as the phantom avenger of SE practitioners has argued issues such as "audience may not know what SE is", "productivity and quality are essence of SE", and "SE focusses on ... applications, is useful to non-experts"
This edit war has degenerated into stubbornness. Can there be any common ground?
- hey you stole my line! :-)
- But seriously, droids and perls, I'd L-O-V-E to find some common ground. C'mon, give us a hint... --Uncle Ed 19:17, 5 Dec 2003 (UTC)
- I read your page, which I essentially agree with. I asked on village pump a few weeks ago about target audience for articles. They agreed that having an intro that "intellegent adults" could read was important. Alas, not much comment on how much readers should know about the subject
- I think the intro should be written for high-schoolers and the body for college students at the most. This does not mean being dumb. But rather to explain complex ideas so that many non-experts can understand them. The experts in SE will not read this page, because they know a lot more anyway.
Hum, this article is biaised, imho. For example, something like Few software engineers manage anyone, so they are not viewed as managers, except by themselves. in "management status" (SE vs Trad. E table) should be refactored a little bit... (Sorry, no time for now to read the entire talk page, so maybe someone else already said that, I'll come back later) gbog
Note (for the record) my source for "only 28% succeed completely, 23% fail outright" the Standish Group, as cited by Robert X. Cringely in this article. I've seen broadly similar estimates from many sources. Dpbsmith 00:40, 23 Dec 2003 (UTC)
This article is an incredibly biased piece that presents itself more as the work of a frustrated student with an axe to grind against the industry and its professionals. There is little valid or useful information here and comparing "software engineering" to "computer science" is a bit off-point. They should be two seperate articles. I'm not about to jump into this snake-pit, but perhaps whoever does could start by looking through this Software Engineering document by the IEEE at [1].
The first paragraph itself needs to be re-written. There is not enough fact and illustration and too much fluff and provocation and confusion. All that needs to be said as the introduction is something like "Software Engineering is, essentially, the application of an engineering discipline to the design, construction and maintanance of software".
while emphasizing productivity and quality. In the year 2000, these technologies and practices encompass languages, databases, tools, platforms, libraries, standards, patterns, and processes.
The above is superfluous. Software Engineering is precisely what I stated up above. While you would hope that software engineers emphasize productivity and quality, that isn't what software engineering is. If it's necessary to include a list of elements of good work ethic like that, perhaps include it as a sub-section. Also, a bulletted list of related etchnologies and aspects should be listed rather than tossing them into the opening paragraph.
The history and prominent figures in software engineering should be expanded or a list of relevant links to them elsewhere on Wikipedia should be provided.
It would be wise to thoroughly study the Wikipedia article on Electrical Engineering for an example of how this entire article could be done better. Hopefully, by someone with non-biased knowledge of the field rather than a grumpy antagonist.
This article doesn't need to be an essay justifying or invalidating the field of software engineering. It just needs to be an article describing software engineering. This entire piece is Software engineering versus .... What is the point of that? This whole thing reads like a first-year CS student's rant on Slashdot.
Cordell 16:40, Dec 31, 2003 (UTC)
- Some key points in the article, that I have tried to keep are:
- treat all SE practitioners with respect and dignity
- explain basic SE concepts so high-school students might understand / choose this career
- recognize that there are many points of view about SE
- Cordell is enthusiastic about the IEEE concept of software engineering, which is an important point of view. The "list of SE concepts" page has a number of links to IEEE documents. Certainly, the IEEE POV could be expanded.
- Unfortunately, Cordell argues that only the IEEE POV is correct. In the U.S., there are about 700,000 practitioners, of which about 25,000 belong to the IEEE/CS and another 25,000 belong to the ACM. This means that the IEEE represents only 3% of practitioners in the U.S. which is much too few to embody the only view. The ACM embodies another 3%, and has a right to advocate a different concept of SE. The rest are not accounted for. For Cordell to impose the IEEE POV on everyone else is arrogant. For example, I believe that SE is not a branch of traditional engineering, because there are so many differences between them.
- The first 4 paragraphs are "a bit of fluff" because they try to explain what SEs do in simple terms, without deciding whether SE is a branch of TE or not (i.e. without being pro or con the IEEE).
I don't mean to suggest that only the IEEE 'specification' is an appropriate one to depict a 'Software Engineer' with, but if you compare other entries for _fill_in_blank_ Engineer, they are more about what that profession entails rather than justifying its place in comparison to others. I may have read the existing Software Engineer article wrong, but it seems like 80% of it is comparing the field to other fields in such a way as to make it appear that software engineers are in need of a boost of self-esteem. Almost like a bowler trying to justify why his 'sport' is on par with basketball, boxing or track and field.
However, I find the "nyah nyah those aren't real engineers!" attitude insulting. Are you suggesting that only people who are directly applying mainstream science to a field are real engineers? So a civil engineer or transportation engineer is not a real engineer? Software engineering requires the implementation of mathematical and complex logical sciences.
The dictionary defines engineering as: the practical application of science to commerce or industry
How does software engineering not fit this? It is the practical application of science to commerce and/or industry. Or is the disagreement that well, most software engineers don't implement laws of physics, mix chemicals or build 3d representation of bridge struts with AutoCAD, so they're faux engineers?
What else shall we label them, then? Software artists? Software technicians? Bit-flippers? Are you saying that it isn't appropriate to call someone an engineer simply because they didn't spend four years of their life in a university to get a fancy degree?
I'm just saying that this article has severe MPD. I'm not pushing the IEEE description of software engineering, but I'm a little put off at how most of the article as it currently exists is nothing more than a list of how software engineering isn't legitimate compared to, say, electrical engineering or raw computer science.
And yes, I know that I could rewrite it myself if I so desired, but I don't know that I could do a satisfactory job for the majority of readers, either. I'm merely trying to provide some reasonable criticism based on how the article came across to me. This is certainly one of the more difficult articles to adequately form that I have seen on this site, so I do recognize the effort of previous editors/contributors on it.
Whether an individual wants to call it engineering or not, that's what most new-hire postings call them. It's what is used on resumes. It's what the industry seems to have settled upon. Thus, it seems reasonable to just accept it and move on with describing the career field rather than rambling on with its justifications.
And for the record, I *am* a software engineer myself. For a big unix OS developer. I personally don't care what you classify software engineers as or if they're 'inferior' to pure CS majors or other engineers. When it comes down to it, my software engineer's salary trumps that of any other engineers that I personally know. So I'm not going to get my undies in a twist over it. *grin*
Cordell 22:34, Dec 31, 2003 (UTC)
Much of your criticism is based on the evolution of the page. The original versions from before mid 2002, mostly listed the failures and criticisms of software. It treated SE as less than CS, CE, EE, and other fields. Look at the first few comments on this page for examples of concern about that emphasis.
This article has slowly evolved to be more of a compare and contrast, between these fields, hopefully treating SE on equal standing with these other fields. I added much of that, and I agree that it reads a little too defensively. I agree that this article needs more evolution.
Yet, it should be noted that in late 2003 and early 2004, SE is still defining itself. It is not clear whether SE is a branch of traditional engineering or not. It is not clear whether SE is a subfield of CS. Only a few years ago (1999), SE was mostly thought of as a small branch of CS.
In the November 2003 ACM Software Engineering Notes, 2 letters debated this point. Dr. William Griswold (UCSD) argued that SE is a branch of CS and they must remain together for the benefit of both. Dr. Peter Henderson (Butler U) argued that SE must shun its failed CS legacy and become a part of traditional engineering. Also the recent (Summer 2003) CCSE curriculum proposal for undergrad SE programs contained a long (in my opinion simplistic) compare and contrast with traditional engineering.
For this article to clearly compare and contrast with other professions makes this article very timely.
It should also be noted that 6 months ago (mid 2003), SE was not listed on the main Wikipedia page, because some argued that it was a fairly unimportant branch of CS (i.e. applied CS). The discussion of these issues in this article was an important part of getting SE its own entry on the Wikipidia home page.
A time will come, when (almost) everyone assumes that SE stands on its own as a proud profession. But, such cultural changes usually take many years. I suspect that the current discussion will be timely for at least 5 more years.
As we learn to explain SE in its own terms, that explanation should fill most of the article. I urge you to help expand the discussion of what SE is, in its own terms, without referring to CS or traditional engineering. The compare and contrast with other fields will then become less important.
This article basically reads "rant, rant, rant, rant..." Fredrik 11:21, 18 Mar 2004 (UTC)
- What would you change to improve it?
- Rewrite it from scratch with a better structure, better focus and better wording. I can't say specifically how I'd change it before making a try, though, and I'm afraid that it probably won't happen. Fredrik 14:08, 2 Apr 2004 (UTC)
- This illustrates one of the characteristics of Wikipedia—in my opinion, one of its strengths.
- Traditional encyclopedias tend to gloss over areas of controversy. A traditional encyclopedia would probably assign the article on software engineering to an author who had written a book or two in the field, and it would be written from a point of view that simply assumes the legitimacy and validity of the practice and proceeds to describe its history, schools of thought, etc. For example, the article in the current Encyclopedia Britannica is utterly uncritical. It simply states things like
- "As a consequence, a new subdiscipline, software engineering, has arisen. The development of a large piece of software is perceived as an engineering task, to be approached with the same care as the construction of a skyscraper, for example, and with the same attention to cost, reliability, and maintainability of the final product. The software-engineering process is usually described as consisting of several phases, variously defined but in general consisting of: (1) identification and analysis of user requirements, (2) development of system specifications (both hardware and software),(3) software design (perhaps at several successively more detailed levels), (4) implementation (actual coding), (5) testing, and (6) maintenance."
- The only hint of a critical point of view is the use of the word "perceive." But the Britannica does not address the question of whether the perception (as an engineering task) matches the reality; whether software construction is really analogous to skyscraper construction; and whether software construction as of 2004 is comparable in predictability, reliability, percentages of successes, and percentages of disasters to skyscraper construction as of, say, 1931.
- In other words, the traditional encyclopedia would discuss software engineering from the point of view of the software engineer (or teacher of software engineers).
- In Wikipedia, it is difficult for an article on a controversial topic to reach a metastable state unless it makes it perfectly clear that the topic is controversial, indicating the nature of the controversy, and stating each major point of view in a way that is acceptable to those holding the point of view. This makes Wikipedia more intellectually honest than traditional encyclopedias. Dpbsmith 01:34, 22 Apr 2004 (UTC)