Wikipedia

Talk:Software engineering/Archive 3

< Talk:Software engineering
Latest comment: 19 years ago by 80.221.54.251 in topic Critical mass
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6

Previous comments

Profession?

Why is PROFESSION part of the definition ? René Bach, Switzerland rrene@acm.org.

Admiral Grace Hopper? Some justification, please

I would like to see some explanation or evidence for the inclusion of Admiral Grace Hopper as a "pioneering software engineer." It's clear that there is at least some controversy over the term "software engineering," and naming her as a "pioneering software engineer" seems to me to be enlisting her on a particular side of that controversy. And I'm not at all sure she belongs there.

I'd like to see some quotation or published remark that shows that she used the term "software engineering" herself and showed an awareness of and alignment with the "software engineering" community and its concepts.

The first Google hit on Grace Hopper is: Grace Hopper, Pioneering Computer Scientist; and the Wit and Wisdom of Grace Hopper page does not contain the word "engineering." Dpbsmith 20:55, 21 Apr 2004 (UTC) Neither does Wikipedia's article on Grace Hopper. Dpbsmith 16:58, 22 Apr 2004 (UTC)

Of course, this biography mentions that she was a "Research Fellow in Engineering Sciences," "Systems Engineer," "Lecturer at the Moore School of Electrical Engineering," "Fellow of the Institute of Electrical and Electronics Engineers," etc. so I can see how this discussion is likely to go... but of course, before "Computer Science" was invented in the late seventies... and much brouhaha there was about that, too... all computer stuff was considered to be a kind of electrical engineering. So she was an engineer... but was she a software engineer? Dpbsmith 21:06, 21 Apr 2004 (UTC)

I'm going to remove her name for now. Please put it back if you have a reasonable case for her inclusion. Dpbsmith 17:00, 22 Apr 2004 (UTC)

How is it that you justify the other names in that list? By what criteria does one determine who the pioneers are? For example, what timeframes would be appropriate for the term "pioneer" to be associated with that list. - Bevo 18:42, 22 Apr 2004 (UTC)
All I can say is that when I looked at the list of names, I thought "One of these names is not like the others, one of these names doesn't belong."
The issue is not who's a pioneer. Admiral Hopper was IMHO certainly a computer pioneer. But I don't think she espoused the viewpoints usually associated with "software engineering." As for the other names on the list... I didn't really consider them. Since the article says that software engineering "emerged as a bona fide profession" starting in the mid-nineties, so I'd think anyone who was clearly identifiable as working in software engineering prior to the mid-nineties would count as a pioneer.
Why did you leave the other mention of Grace Hopper in the article if you don't feel that she was a software engineer? - Bevo 18:44, 22 Apr 2004 (UTC)
Because I didn't notice it. Now you've called my attention to it, I see that the context seems to be merely the role of women in computing generally. It seems to me that the sentence says: Hopper and other women filled "programming" jobs during the "1940s, 1950s, and 1960s". It also, it seems to me, is saying that those decades were "the first several decades of software engineering."
If all software writing done in the 1940s, 1950s, and 1960s was "software engineering," then certainly Hopper was a very notable software engineer. And indeed some parts of the article do seem to take the view that all software writing is software engineering.
However, I believe that the phrase "software engineering" these days usually carries some definite semantic baggage with it: it is a specific approach to the task of writing software. I think this is clear from other parts of the article. For example, one part of the article specifically classifies Edsger Dijkstra, Donald Knuth, and Alan Turing as not being software engineers. Hopper's most notable contribution might be the development of COBOL; Dijkstra's, the development of ALGOL. These are very parallel achievements and to me would suggest that they belong in the same category, as does Hopper's original background in mathematics.
In other words, if "software engineer" is just a courtesy title for "good programmer," sure, she was a software engineer. But if "software engineer" means management techniques, adherence to well-specified methodologies, use of CASE tools, etc. then it's not so clear. Dpbsmith 19:29, 22 Apr 2004 (UTC)
Perhaps Kent Beck should be removed from the list as well. See especially SE pioneer David Parnas article http://www.xp2003.org/xp2002/talksinfo/parnas.pdf - Bevo 02:42, 23 Apr 2004 (UTC)

Grace Hopper built the first compiler for the Mark 1, and compilers are probably the most important tools that SEs use. Also, she is famous for "it is easier to get forgiveness than permission" which is a very XP way of working. She did not set out to be a software engineer, but David Parnas probably did not set out to be a software engineer, either.

As for who should be on the list, that is an excellent question. The CS page debated a similar question for about 6 months last year. The criteria I used, was that I wanted 5 or 6 names from the list of software engineering topics pages that gave a sense of how big and broad the field is. Beck and Humphrey go together like yin and yang, showing opposite ways of doing process. Hopper was from the first generation, Beck is from "the most recent" generation. Once again, like yin and yang showing change over time. Boehm, Brooks, and Parnas are the heros from the first generation to meaningfully use the term software engineering. Yet, they are not the first generation to work on these issues, nor were they the last.

There are lots of ways to choose the top 5 or 6 names.

It's not a question of "who's the top," it's a question of "what does software engineering mean?" And the more I look at this article, it seems to me that the article has a severe, severe problem. "Software engineering" is being used to mean at least two distinct things.
  • As an umbrella term, for anything having to do with the production of software
  • As a specific term for a specific school of thought about the organization and procedures for developing software... a school that draws a distinction between engineering, science, art, and craft and distinctly advocates the use of an engineering model for producing software.
Now, the Pioneers list from List of Software Engineering Topics obviously uses the "lumper" definition, as it includes Edsger Dijkstra and Donald Knuth... yet Software Engineering uses the "splitter" definition when it declares that Dijkstra and Knuth are not "software engineers," but "computer scientists."
Personally, when I look at the Pioneers list, I certainly put Kent Beck, Grady Booch, Fred Brooks, Watts Humphrey, Winston Royce, Gerald Weinberg, Ed Yourdon in a different category from Backus, Dijkstra, and Knuth. And to me, Admiral Hopper belongs with the latter, not the former.
The supposed definition that heads the article is no help. In fact it's a mess. It says "the profession concerned with creating and maintaining software applications by applying computer science." Now, the term "computer science" did not exist prior to, I dunno, the early seventies. It seems to me it's pretty hard to decide whether Backus or Hopper or the ALGOL folk can be properly described as "creating and maintaining software applications by applying computer science." It's even harder for me to figure out where, in "The Psychology of Computer Programming" (Weinberg), or "Handbook of Walkthroughs, Inspections, and Technical Reviews" (Weinberg) or "Extreme Program Explained" (Beck), you can point to an example of the "application of computer science."
Meanwhile, throwing in that term "profession" clouds the issue further. Someone who contributes to Linux without being paid for it is doing it for the love of it, and is therefore by definition an amateur. If software engineering is a profession, than most Linux contributors are not software engineers... at least not while contributing to Linux. That makes no sense to me.
Anyway, I still think that if you write "Kent Beck, Barry Boehm, Fred Brooks, ___________, Watts Humphrey, David Parnas," that "Admiral Grace Hopper" is not an obvious fit.
Dpbsmith|Dpbsmith]] 23:18, 23 Apr 2004 (UTC)
Do you consider the "Extreme Programming" methodology to be an engineering methodology? - Bevo 01:04, 24 Apr 2004 (UTC)
An "engineering methodology?" What's that? My limited experience is that—outside of software—people who call themselves "engineers" don't talk about "methodologies." Dpbsmith 01:23, 24 Apr 2004 (UTC)
Indeed, I just checked:
  • "aerospace engineering methodology" = 2 Google hits
  • "chemical engineering methodology" = 28 Google hits
  • "civil engineering methodology" = 7 Google hits
  • "electrical engineering methodology" = 10 Google hits
  • "mechanical engineering methodology" = 18 Google hits
  • Your search - "Mining engineering methodology" - did not match any documents
  • "software engineering methdology" = 5560 Google hits
I don't know exactly what that means, but it has to mean something. Dpbsmith 01:23, 24 Apr 2004 (UTC)
Read the article Methodology. Look at the use of the word in this Software engineering article. Google for "engineering methodology" and I get 18,000 hits. Google for the term "software engineering and methodology" and I get 19,300 hits. It's a well-established term. - Bevo 01:36, 24 Apr 2004 (UTC)
I know what a "methodology" is. And I know what a "software engineering methodology" is. I am questioning the phrase "engineering methodology" because I don't believe that other branches of engineering indulge much in "methodologies."
All of the examples in the Methodology article refer to software engineering or project management, and if you changed the title to "Software Engineering Methodology," only two sentences would need rewriting.
Change your Google search from "engineering methodology" to "engineering methodology" -software and the number of hits drops to 4560, most of which concern information systems or other computer-related topics. Change it to "engineering methodology" -software -information to exclude these and it drops to 1660.
Software engineers talk a lot about "methodologies." Other engineers do not. Dpbsmith 20:06, 24 Apr 2004 (UTC)
I suppose that indicates that "software engineering" is not a true engineering endeavor. Perhaps you don't get to the maturity of legitimately using the label "engineering" until you only have one proven and universally practiced way to do something. - Bevo 14:22, 25 Apr 2004 (UTC)
There are many ways to build bridges, many ways to build houses, many ways to build radios. Engineering has many, many methodologies, not just on. Perhaps engineers do not do engineering?

Oh, that Conclusion

...that says how big, important, proud, etc. the software engineering profession is? Does it communicate any information at all? Or is it pure marketing?

I don't suppose it would be possible to quietly remove it or otherwise put it out of its misery? Reminds me of an old promotional film for Project Whirlwind which ends:

We have told you the story of one problem recently solved on one digital computer. Multiply this by hundreds of problems being handled routinely by a hundred such computers and you have an idea of the current importance of the digital computer as a new tool to help scale some of the hitherto insurmountable peaks which span the domain of man's activities!

Cue music. Dpbsmith 16:25, 29 Apr 2004 (UTC)

You make a good point. I looked around and found no other articles on Wikipedia that have conclusion sections. And this text is very (overly?) "apple pie".
Here are 2 reasons to keep a conclusion like this one. First, the text before the conclusion is a major downer: all about the criticisms of SE. It would be nice for those who read the text from front to back to be left with a positive vibe about SE. People often remember what they read last. One alternative is to find some positive or neutral content to put at the end. Second, many technical articles (though not Wikipedia, yet) identify a few clear points for readers to remember, these key points are often restated in the conclusion. I wonder what handful of key points the other authors of theis article want readers to remember, and where should they be listed?

Restructuring of page

I hope you agree with breaking up the software engineering article in several smaller articles (and moving lots of talk to the archived talk). I know, this was very rough cut, but I hope time will smooth it out again... :) --denny vrandečić 21:59, Jun 27, 2004 (UTC)

Thanks, it really needed it.

Disagree with the latest precis at the top of the article.

The latest commenting-out of "poorly formed sentences" in favor of non-nuanced lists is a regression. Better to have the detail than the stereotypes in the current lists which make up the wikilinks. The current changes to the first paragraphs bowdlerize and trivialize it. The software tools which were previously mentioned aren't necessarily in the replacement lists. Ancheta Wis 01:43, 22 Jul 2004 (UTC)

I agree. A common mistake in hypertext documents is to assume that readers will click on all of the links and understand what all of the links mean. If that happened, readers would have to click on everything in Wikipedia to understand 1 page.
I believe that each page should stand on its own, at least a little bit. A casual reader should find enough details on each page to understand something about the topic, without any additional clicks. And the text around each link should give the reader enough context so they can choose whether to click on a link or not. Note: This principle is the opposite of "information hiding" that is used to design software for computers.
This means that the first paragraph or so of the SE article should list enough concrete applications that naive readers would understand (a little bit) what we mean by "application", and should list enough technologies and practices, that they would understand (a little bit) what we mean by "technology and practice".
Examples were removed under the guise of "peacock terms". But, there were no peacock terms in the text. Peacock terms are "an important..." "one of the most important..." "one of the best..." "the most influential..." "a significant..." and so on.
Another stated principle of Wikipedia is "Show; don't tell". Concrete examples are much more like "show; don't tell" than abstract generalizations. So, I have reinstated the examples.
The only real reason to remove examples I can think of, is because someone disagrees with whether the examples are valid. For example, some argue that embedded-software is engineered, but office suites are not because they have so many problems with crashing and security. But, that would be a debate over what software engineering is, rather than a debate over peacock terms.
I urge Kenny to explain his rationale for deleting the examples. Perhaps then we can find a way to change the intro to meet our common goals.
embody social and economic value, by making people more productive, improving their quality of life, and enabling them to do things that would otherwise be impossible. help developers, by improving productivity and quality. -- it is communist slogans, not definitions. Abstract. Senseless. Metaphoric. Emotions in form of words. Better to write something like this: Software is usefull. For exaple word processor is very usefull in text editing. For more examples see ... Software created by prgammers with software tools. Most common software tool is compiler. For more software tools see programming tool
Long enumerations is sentences used in Ericksonian hypnosis to misslead consciousness. Example: A, B, C, D and F and may be also G, H and J, if K and L will join too will do M, N and O for P, Q and R for S, T and W.
Write "Examlpes:" before examples. Do not oveload with exaples, I think 1,2 3 is enogh. Write most common examples.
Thank you. Kenny 14:32, 2004 Jul 28 (UTC)
I can agree with you about separating out examples into a separate sentence using the prefix "Examples:". I did that.
I do not yet agree that examples should only have 1,2, or 3 examples is enough. On the List of software engineering topics page, there are more than 100 applications and more than 200 technologies and practices. It may take a list of 6 or 8 examples to show diversity of applications / technologies and practices.
A too lot of examples is not effective. Please read The Magical Number Seven, Plus or Minus Two. This number of words in sentence is ideal. List of software engineering topics is full comprehensive ordered list. Kenny 09:54, 2004 Jul 29 (UTC)
Many, many clear and important sentences have more than 9 words. The point of writing is to communicate clearly. Please avoid using simplistic rules to justify bad writing.
Let me assure you that I live in the U.S. and I oppose communism. I believe it is important to show SE in a good way, just like everyone else should want to show their favorite topic in a good way. That is common sense communication. The reason to say the technologies and practices are there for productivity and quality, is because it is true. If you do not care about productivity or quality, then you may be a programmer, but not a software engineer. The reason to say that applications improve people's lives, is because it is true. People enjoy playing video games, which would be impossible without software. People have lower cost telephone service (more value) because of software. The Agile Software Development publishes many papers and books about creating "social and economic value".
Ok, yes, productivity, quality, entertaiment is important. Also there is a lot of other important topics, and not only SE improves quality.
Critic of "SE applications embody social and economic value by making people more productive"
  1. this article about SE, not SW and SW applications.
  2. Wikipedia:Avoid_peacock_terms
  3. IMHO, I see nothing interesting, usefull, in this sentence. The sense of this sentence is same and "Pencil embody social and economic value by making people more productive". The only meaningful interpretation on this phrase I found is: "Software is usefull for people."
  4. After I've read this sentence, I have this questions:
  1. What is "social and economic value"?
  2. Making people more productive for ....?
  3. Only SE applications are valuable?
  4. How SE applications making people more productive?
  5. SE applications make people only more productive?
  6. SE applications make only people more productive?
I agree that this page is about SE and not SW. To contrast, SE people write core applications, while business people write spreadsheet templates, lots of people write VB scripts, artists write animation scripts, and scientists write simulations. All of that is software. Trying to clarify this distinction is a good reason to show the diversity SE applications.
Scientific applications are more about understanding nature than about making people productive. Software engineers write the compilers that make the scientists more productive. Animation scripts are more about making visuals to an artist. Software engineers write the animation engines that make the artists more productive. SE has a different emphasis than other professions that write software.
Yes, this is right. Kenny 15:46, 2004 Jul 29 (UTC)
We agree on that.
I believe that one important distinction, is that most SE software is purchased for one reason or another. (Note that the free software projects often recreate programs that have been sold for a long time.) Users buy the software because they want to use it for a reason. In office automation and robotics, it is to improve the productivity of workers. In the case of visual special-effects and video games, it is to have fun. These are examples of "social and economic value". Perhaps "value" needs to be explained better or use better examples.
Also, I believe that the first 2 or 4 paragraphs should show what SE is and start to explain that it is not all software. These paragraphs cannot make an exact distinction, because that would take too many words. (That is what the whole article is for.) But these paragraphs should start to introduce some of the key distinctions.
I'll be back in 3 days. Software engineering need nore rework. Kenny 19:20, 2004 Jul 29 (UTC)

Don't see the point of this section or sentence

There is currently an entire section called Software engineer whose content is:

A profession, which cares with creation of software with software engineering called software engineer, programmer or developer.

I tried to rewrite it, but I don't understand what it means or what the purpose of the section is supposed to be. Does it mean:

A software engineer is a professional devoted to the creation of software via the application of software engineering principles. A software engineer may also be called a programmer or developer.

If not, what does it mean? Is it worth a whole section just to explain that a "software engineer" is someone who does "software engineering?" [[User:Dpbsmith|Dpbsmith (talk)]] 16:22, 30 Aug 2004 (UTC)


I think that your's is better but, as someone with a degree in "software engineering" I am a little disturbed by how much this article likens software engineers to programmers. My University makes a clear distinction between a computer engineer (from the college of engineering), a computer scientist (from the college of science), and a computer information systems major (from the college of business). True, in all 3 programs we learn to code, but the purpose of software engineering (a part of computer engineering) is to take a set process to the development and integration of software into a system. Engineering is the application of science into the real world and can't be done properly if you understand only how code works and not why code works. I'd like to see this article (and the world in general) come to some clearer definitions between programmers, application architects, and software engineers. Cavebear42 23:36, 30 Aug 2004 (UTC)

True that! DaBeast

To make more international

To make this more international, the issues such as economics and famous people needs to become more international (less biased to U.S.). To do this, we need data from Europe and Asia. So, what is the economic impact of SE in Europe and Asia? Who are the SE pioneers in Europe and Asia?

Remove

Removed the following sentence, because it directly contradicts itself.

Without the engineering approach, the code can be difficult to maintain or debug, but an engineering approach does not guarantee quality code without bugs.

Waterfall

"The waterfall has been widely discredited in practice, though many people still seem to idealize it."

Where and how has "the waterfall been widely discredited?"

I do not advocate it, but I want to see this sentence clarified and evidence cited.

If it means simply "The waterfall method is no longer in fashion" or "large developers like Microsoft do not use the waterfall method" then that is what should be said.

If it means "The waterfall method has been shown to be inferior to other methodologies" then that is what should be said.

In both cases, evidence for the assertion should be cited.

The Spiral model (and others) succeed because the Waterfall fails. I am not aware of a single large project that has ever been successfully driven by a requirements doc, except where that project had undergone many previous iterations. Even the US DOD agrees about this. The pragmatists in SE widely agree that the Waterfall is a catastrophe.
However, good criticism is hard to say. Alas, the Waterfall is still very fashionable with many people (for example formal methods people, and some project management people) who use it justify their own point of view. For them, the Waterfall is far more superior and successful to the Spiral, Chaos, Scrum, or other models. Also, the Waterfall is very simple, and most SE textbooks begin by teaching the Waterfall because it is so simple.
Please help find a better way to say this.

What really bothers me about software methodologies is my impression that they simply come in and out of fashion for no particular reason other than the personal influence and salesmanship of exponents. Each methodology is always accompanied by flat assertions that it has been proven in practice, but the "proofs" I've seen seen usually anecdotes ("case studies,") and are often accompanied by unrealistic requirements for success (must have everyone's buy-in, must have the backing of upper management, etc.) They are often discussed in a way that implies a background of data which is always assumed but never actually presented.... [[User:Dpbsmith|Dpbsmith (talk)]] 19:41, 6 Oct 2004 (UTC)

Good point. This is one of the main criticisms of all methodologies. The page Methodology (software engineering) lists a couple more related criticisms.
Methodologies was one of the main areas of software engineering over the last 20-30 years. Even today, there is a huge amount of time and energy devoted to methdologies(including RUP, Agile, CMM ...). I think this SE page should *briefly* discuss methodologies and point to the other page. But like I said, saying it well is hard. Do you have any thoughts on what it should say?

Why are we making judgements on how well a process works? I think we should state what the waterfall method is, since it is so prevalent, and leave it at that. Then when we discuss iterative methods or the spiral method, we can say that those methods attempt to build on the waterfall model by accounting for the element of risk. Of course, each methodology will have something unique to itself, something in its design/philosophy that accounts for something the others don't.

Remove

This article attempts to be neutral on this issue, but errs on the side of being independent to clarify the differences between fields.

Quotes

These 2 quotes are pretty cynical and down. In a similar vein, one could describe Winston Churchill as "a politician who lost a bunch of elections." Can we not find much better quotes about SE?

  • I don't believe you can get much better than Edsger Dijkstra and Fred Brooks, and I would be opposed to replacing these quotations with gee-whiz happy talk. [[User:Dpbsmith|Dpbsmith (talk)]] 17:34, 19 Nov 2004 (UTC)
    • I think one can almost always do better than Dijkstra. The only person more cynical the Dijkstra is Neumann. Boehm and Parnas would both be much better (more true to SE) than Dijkstra.
      • What the heck do you mean by "more true to SE?" I cannot imagine someone saying "let's remove the quotation from John A. Roebling and replace it with one from Othmar Ammann because Ammann is more true to civil engineering than Roebling." This whole article reads more like a marketing department's white paper than an encyclopedia article about a branch of engineering. [[User:Dpbsmith|Dpbsmith (talk)]] 20:36, 23 Nov 2004 (UTC)
        • You have one point, but only one point. Dijkstra was reknowned for his goals to make SE more mathematical. He made many important contributions to SE. But, his biases show he is rather narrow-minded, perhaps fanatical. He also showed a lot of contempt for commerical software and practitioners.
        • On the other hand, Parnas and Boehm have both worked in industry, and except for a few stray comments here and there, they both showed respect for commercial software and practioners. They also tolerated a much wider range of ideas of what good SE practice is.
        • I believe that one cannot define SE without including practice, and in this respect Dijkstra is totally out of touch with reality.

Kent Beck

Why isn't he a pioneer? His promotion and popularization of the XP concepts seemed pretty radical and pioneering to me at the time. And even where the whole XP method hasn't been adopted, a lot of its ideas have influenced the development process. -- Key45 23:10, 23 Nov 2004 (UTC)

  • He is a pioneer of extreme programming, certainly, but he isn't a pioneer of software engineering. He is a notable and important recent contributor to the field of software engineering. A pioneer is "One who ventures into unknown or unclaimed territory to settle. 2. One who opens up new areas of thought, research, or development: a pioneer in aviation." Beck didn't "open up" the field of software engineering. That was done in the 1970s. In fact, Robert L. Glass defines the "pioneering era" as 1955-1965. "Structured Programming" emerged in the early 1970s. Naur et. al wrote "Software Engineering: Concepts and Techniques" in 1976. I don't know exactly when Beck was developing the "Extreme Programming" methodology, but it must have been in the 1990s, a couple of decades after the pioneers. [[User:Dpbsmith|Dpbsmith (talk)]] 01:30, 24 Nov 2004 (UTC)
    • "Unclaimed territory, opens up new areas of thought...". I'd say that describes Beck to a tee. He greatly expanded the way people think about software engineering, even if he didn't invent it. I don't think basing the distinction on date alone is correct. Wouldn't you call Burt Rutan a pioneer in aerospace engineering, even 40 years after the moon shot and 100 years after the Wright Brothers? Also, didn't you argue for his inclusion earlier in this page (in the Grace Hopper section)? -- Key45 17:17, 24 Nov 2004 (UTC)
      • Burt Rutan and Kent Beck are innovators or revolutionaries, not pioneers. That does not diminish their contributions. Hu 17:42, 2004 Nov 24 (UTC)
      • It's all arguable, but I would have called Rutan a pioneer in the use of composite materials in aviation and a pioneer in the commercialization of spaceflight; I would have said Frank Whittle was a pioneer in jet propulsion, and that Lindbergh was a pioneer in transoceanic flight; but when I think of "pioneers of aviation" I think of Chanute, Langley, and the Wright brothers. [[User:Dpbsmith|Dpbsmith (talk)]] 18:10, 24 Nov 2004 (UTC) P. S. No, I never argued for Kent Beck's inclusion as a pioneer. I wasn't paying a lot of attention to aspect, really. IMHO Grace Hopper was a pioneer in computing, but does not belong to the field of software engineering. IMHO Kent Beck certainly belongs to the field of software engineering, but did not pioneer it. Your mileage may (and obviously does) vary. [[User:Dpbsmith|Dpbsmith (talk)]] 18:14, 24 Nov 2004 (UTC) P. P. S. And, yes, I see that the article on Lindbergh calls him an aviation pioneer. But the article on Burt Rutan does not...
        • I would much rather put both Beck and Humphrey on the page as pioneers. They complement each other. But, Beck helps to show that the field is much more than what a bunch of researchers thought about 30 years ago. SE is a living, breathing field that still is evolving. -- The Phantom Avenger

Meanings

I've reinserted the following which I believe to be accurate:

As of 2005, in common parlance the term software engineering is used with at least three distinct meanings:
  • As the usual contemporary term for the broad range of activities that was formerly called programming or systems analysis;
  • As the broad term for the technical analysis of all aspects of the practice, as opposed to the theory of computer programming;
  • As the term embodying the advocacy of a specific approach to computer programming, one that urges that it be treated as an engineering profession rather than an art or a craft, and advocates the codification of recommended practices in the form of software engineering methodologies.

The term is really used in all these senses, even if some advocates would like it to be otherwise.

Why was it removed?

If, after introducing these terms, it is felt that the article should discuss only one of these meanings for software engineering, it should say so and then continue. Anything else muddies the water. Dpbsmith (talk) 21:22, 15 Feb 2005 (UTC)

RUSSOFT

What is RUSSOFT? Do we have an external link to more information? RJFJR 21:08, Feb 20, 2005 (UTC)

  • [http:\\www.russoft.org www.russoft.org] is an external link to RUSSOFT. The other organizations listed in the article are wikilinked (such as IEEE). I don't know how we want to handle this for consistancy (wikilinks only, this one as external, remove this, leave as is...). I'm not even positive it is an organization in the same way IEEE and ACM are.

Removed material

The intro section was very choppy (a lot of paragraphs each with a few sentences). I consolidated them and removed the following material. I felt the following material, while detailed and interesting, was not directly related to software engineering. I have moved it here in case there is disagreement. RJFJR 19:32, Mar 12, 2005 (UTC)

This edit opens up a long and divisive debate. There are many issues.
    • Concreteness: Many believe that examples make text much more concrete and comprehensible. Others want text to be high-level and abstract.
    • Audience: A related question, is who should the pages be written for? Most writers are in college or past college. However, there is evidence that most readers are high-school students, or other people who are not familar with a topic. What is obvious and irrelevant to a CS student or grad, may be very unclear and important to a high-school student or someone who is thinking of returning to college. Of course, Wikipedia has yet to define its target audience very well. The lists make it accessable to a much broader audience.
    • Definition: Saying that SE emphasize quality does not really say what is and is not SE. Some (especially in aerospace, SEI, etc.) have argued that SE is about life-and-death apps, and video games are not SE because a lower standard of quality applies. Yet, the U.S. census from 2000 made it clear that people who write normal, everday app view themselves as SE. Using the broader examples allows this larger community to be included, without pandering to the elitists.
    • Style: Your main complaint is choppiness. The original version was sentence prose. One Wikipedian hated the prose list, but was willing to stop arguing after making it an example list. This was maybe 6-8 months ago.
    • I will replace the examples in a couple days, unless someone finds a new way to think about all this. -- The Phantom Avenger for SE


Sorry, I didn't mean to cause a disturbance. One of your points mentioned quality as it relates to software engineering, this sounds like something that could be (and should be) expanded into a section. Can we add a section for definitions under terminology and put some of the material you want to put back in there? I'll have to look at this some more later. RJFJR 15:13, Mar 15, 2005 (UTC)

Please do not apologize. You are correct that the sentences are choppy and need to be improved. And, they had sat there for many months, without change. While I have fought in these battles in the past, I do not mean to imply that you intended any harm.
The big dilemma I see, is that most readers will not read past the intro. So, all relevant info for the main definition should be in the intro. Only alternative, historical, and other weaker info should be moved down into the definition section. Also, the intro from last week was not particularly long, in terms of word count. The trick is to make is tighter and smoother. Will think about this. -- The Phantom Avenger for SE

Removed the following text. This is a researcher fantasy. I suspect that every truly useful bit of research is very quickly adopted into practice. At least 1 practitioner believes that researchers are too often self-deluded and research gets ignored only when it is junk. Practitoners need every useful method and technique that they can find, regardless of when or where it comes from.

In the last years software engineering made big steps from the research point of view. But the research output has been slowly introduced in the industry. So probably, nowadays is important to transfer the advanced research output into daily practice, instead of developing new methods and techniques.


I replaced the second paragraph which was

Software applications improve user productivity and quality of life. Examples include embedded systems, office suites, operating systems, video games, and world wide web. Technologies and practices improve the productivity of developers and the quality of the applications they create. Examples include algorithms, data structures, databases, languages, libraries, patterns, processes, and tools. Processes encompass analysis, specification, design, development, and testing.


The paragraph I substituted tries to answer the question "what is software". If someone chooses to replace it please consider putting my version here for possible discussion or borrowing from. The version I inserted may need some work on the choice of wording (could be simplified some). I need check if we have an article on measuring code in millions of lines of code. I apologize in advance if I've made the article worse rather than better.RJFJR 17:53, Mar 25, 2005 (UTC)

I think your explanation of "why SE matters", mostly the reliable million line apps is important. However, there is a whole page computer software devoted to the question "what is software?", so I don't believe that that belongs here. Also, there are no concrete examples of what apps and technologies are. People in the field will have no problem, but people outside the field probably do not know.
Apps are used in the devices listed. I didn't want to bog people down with things like embedded system and real time programming (even though there some differences in how you do engineering for those conditions.) I'm not sure how to descirbe SE techniques without being too technical. The second paragraph as I wrote it is a tad long, may need pruning. On the other hand probably need to add an example of the kind of app you have on a PC (to go with what are mainly embedded examples). Any ideas for non-technical examples of SE techniques? RJFJR 20:00, Mar 25, 2005 (UTC)
After thinking about it for a couple days, I basically agree with your intro. Good job. -- The Phantom Avenger for SE

For Your Info: Yesterday (March 29, 2005) this page was in the top 10 on Google search for "software engineering". Until yesterday, this page bounced around between about place 11 and place 20. Pages Usually bounces around in a range of 5 or 8 positions. Since this page has been climbing, it should routinely be in the top 10, within a month.

This means that this page is useful enough for lot of people to appreciate it. I believe the reason for popularity is because this page has real content and real sentences, as opposed to boring lists like the "computer science" page. Also, it is neutral enough to not get hung up on traditional (out of date) points of view.

Anyways congratulations to all the authors of this page. -- The Phantom Avenger for SE

    • High Five, everyone! RJFJR 02:20, Mar 31, 2005 (UTC)

'Room for improvement' has room for improvement

The section currently headed 'room for improvement' ironically has room for improvement. It was a section on how software is often buggy and insecure but that improvements in software engineering procedures and technologies can improve this. It's been tightened to the point where it is a little too tight. Anyone have any material we can add to clarify this? RJFJR 02:35, Apr 7, 2005 (UTC)

Excuse me?

Extreme Programming is the best-known agile process. In Extreme Programming, the phases are mixed up. Advocates say this is much more effective. Testing is done first, to provide concrete goals for development. Coding comes next. Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature - blurring together design and code - is common to all the other agile processes.)

How can testing "be done first?" If no coding has occurred yet, what is there to test? Dpbsmith (talk) 10:39, 7 Apr 2005 (UTC)
You write the unit test as some sort of semi-formal specification to test the design contract of a future implementation. That way you can think of the interface of code, while doing something useful (coding) at the same time. Example: you want to write a certain collection class. First you write the unit test, in which you create an instance of the (not yet existing!) class in code. Then you do a few addition and removal operations, and write code to check the contents and size of the container. This test will of course not compile. So then you write an empty class that conforms to the newly-designed interface. You adapt some changes to the test if needed, and you compile. This time, the unit test will compile, and will fail immediately (otherwhise your test is bad). Now you continue implementing methods, during which you constantly test, expand and adapt the unit test. I hope this clears stuff up. Wouter Lievens 16:51, 7 Apr 2005 (UTC)
That's completely different. "Developing unit tests" is not "testing." Please clarify the paragraph language to explain that unit tests are developed before developing the code, which is perfectly sensible (and a common practice for decades), not that "testing is done first," which is absurd. Also, if the unit tests are actually implemented, then surely that counts as "coding," i.e. it is just saying that one part of the coding, the unit tests, is performed before other portions. Note that this is not that different from insisting that well-specified requirements be defined before coding begins; unit tests are simply very well-specified requirements. Dpbsmith (talk) 17:37, 7 Apr 2005 (UTC)
You're indeed correct. The paragraph (with which I had nothing to do :p) requires a rewrite. Wouter Lievens 19:12, 7 Apr 2005 (UTC)

Formal methods: cleanup

I removed most of the contribution of 204.134.9.1 (April 5), as it fits more into a discussion of personal views (i.e. here) than it represents a neutral point of view.

The general problem is that formal methods can not be seriously discussed as a sub-chapter of a software engineering article. So we better keep here only a value-free short note that there is something like “formal methods” too.

In particular the contribution is focused on writing and validating code. People apply formal methods for any kind of application. Creating conventional code (like C++ etc.) using formal methods is just one – not very sophisticated – possibility to use their power. For instance, a state machine can be defined without writing one line of code. There are several methods to validate the state machine (infinite loops, dead locks, states which cannot be reached etc.). A designed state machine can be expressed as a set of boolean equations by an automatic process. This set can be then executed by an other automatic process (the rules of boolean algebra are well known). Doing so one creates a computer control application, but there is not one line of code behind it. This is the really interesting part of formal methods, the validation possibility is just an other aspect of it.

This is a formal methods fantasy. I would like *anyone* to show me a 'state machine that can be expressed a set of boolean equations' that actually does something useful that is not written *some* form of programming language (whether graphical or textual). Even ML and OCAML are now universally recognized as programming languages. And, any form of validation that can be applied to boolean equations can also be applied to code. The above paragraph contains more wishful thinking than the original article contained opinion.
Thowa 10:42, 17 Apr 2005 (UTC): None of the formal methods can be shortly explained within a Wiki-discussion. But let's do a short example, a more interested reader might find as a useful starting point to understand how powerful formal methods in practise are.
Let's create a finite state machine (FSM) having two states "Eat" and "Sleep". This FSM shall communicate with two external objects: a digital input (di) and a timer (ti). The digital input can generate two signals: “true” and “false”. The timer generates one signal “over”. The timer accepts also a command “start” (which does a reset and starts the timer). We create an input and output dictionary which can be used by the FSM:
Input dictionary
{di_true, di_false, ti_over}
Output dictionary
{ti_start}
What does our example FSM do? It starts in state “Eat” and goes to state “Sleep” in case the di was set to “true”. Entering the state “Sleep” the FSM starts the timer. To go back to state “Eat” the timer must be “over” (ti_over) and the di must be changed to “false” (di_false). Please print the FSM transition diagram on a piece of paper to avoid any misunderstanding. To create the executable specification we need to create state transition tables for each state of our FSM:
State Name Condition(s) Actions(s)
Eat (current state) Entry action n/a
Sleep (next state) di_true n/a
and
State Name Condition(s) Actions(s)
Sleep (current state) Entry action ti_start
Eat (next state) di_false AND ti_over n/a
An automatic process can generate a set of equations which fully express the above specification. This set could look like this (note that this is already a kind of machine code, so it looks criptical, but I enter it here to show the “magic” behind the executable specification):
S1 N2 V4
S2 E1 N1 V3&2
where S represents the current state, N the next state, E entry action and V condition (& means AND). For instance the first line means “in state 1 (Eat) go to state 2 (Sleep) if the boolean condition 4 (di_true) is true”.
Some words about the used boolean algebra here. In the presented concept it is the positive logic algebra and not the boolean algebra (i.e. NOT is forbidden). The reason is simple: in the software world we have very seldom signals which can be negated. Lets take for instance a sensor which delivers temperature: temp_low, temp_good and temp_high. What would be NOT temp_high? So in the above concept we only look if a signal exists or not. Some signals cannot exists in parallel, e.g. We cannot have at the same time di_true and di_false.
The above equation plus the description of the I/O dictionaries can be now read by a standard executor (which might be a part of the OS) and executed.
I like your example very much. I copied it to the formal methods page as the "example" section. Thank you.
As you can see up to now, we did not write one line of code in any conventional programming language. Of course, this method can be applied “only” to design the control part of the application. All the peek/poke operations (translation of real signals to names accepted by the FSM and vis-a-versa) as well as pure mathematical calculations have still to be coded in the conventional way, but the improvement (reliability, maintenance and time-to-market) in software design is enormous.
I disagree with your premise. Yes, you did not write in a "conventional programming language" but you did write in a "programming langauge". If you claim to have an "excutable specification" then the specification must be written in a mechanically clear form. Also, I have no way to know whether your spec improves reliability or maintenance or time-to-market. Those claims are just hot air. Perhaps my guru friends would have written the same program in C++ much faster than you wrote your executable spec.
Thowa 07:31, 26 Apr 2005 (UTC): I can agree with you that any kind of „mechanically clear form“ can be called a programming language. But then I would say that this „FSM-language“ is an enormous progress in development of programming languages compared with all we have else. The step forward is the syntax and methodology behind it.
1. The syntax: instead of writing thousands of lines of cryptic text which can only be understood by certain gurus you plot pictures and fill out tables. The result of your work can be understood by your management, can be discussed with your customer and does not need any further design documentation as it cannot be better explained in words.
I think we agree on what you say in these 2 paragraphs. When a mini-language is smaller and clearer, it is ofter better for everyone. -- PASE
2. Methodology: the difference in thinking is here critical. For instance in OOP you think in terms of objects. You try to express your problem (application) as a set of black boxes communicating with each other. In FSM you try to express your problem in a form of situations (states), which is a much more realistic approach. If you design a system of 10 FSM, each of them consisting of 10 states, you covered theoretically 10^10 possible situations your application can be in. Even if we know that there are several impossible combinations of FSM states, it is impressing to be able to see how many situations do we cover. In OOP it cannot be possible because we don't think situation oriented – you can count only your black-boxes. Besides this can you imagine how many lines of C++ code would be necessary to cover 10^10 cases? In practice all we can do in code is to design the sunny day scenario and cover the most obvious error cases. The rest is just „almost impossible“, „happens very seldom“ or „can be accepted“. Therefore the most of the software is as it is (i.e. buggy). You will also make bugs in your FSM design of course, but those are on a much higher level of abstraction (something like if (a=b) instead of if (a==b) will never happen in your „code“) and the (automatic) validation methods are by far much more powerful than what you can do in code.
I think the above statements explain also a little bit what I meant by „improved reliability, maintenance and time-to-market“, but you can still think it is just „hot air“. Luckily there is some „hard ware“ in place: Lucent published some years ago "an article in Bell Labs Technical Journal", where they explain how they introduced the VFSM (virtual FSM) technology in their labs and what were the results in terms of reliability, maintenance and time-to-market after several hundreds of projects done (see p. 15). Since then, there has been done a lot of improvement and the methods became much more powerful. Unfortunately my own experiences are not published yet, but I promise that this will happen soon... ;-) --Thowa 07:31, 26 Apr 2005 (UTC)
This is an interesting argument. My first response is that most code in most apps is not applicable to most formal methods. I work on a commerical app that plays a sound, whenever a file transfer completes (among other stuff). This code is about interfacing with the OS and saving and setting user preferences. No formal method will make that better.
Another example is parser generators. They are very nice examples of formal methods, by expressing syntax simply and clearly. But, most programs do very little parsing, so parser generators do not help most programs. Of course PGs do help compilers and a few other programs.
Every new formal method technique helps a little bit. I hope your VFSM gets used. But, very few formal methods have been widely used, unless they are put into compilers, like weakest preconditions, where they are used automatically and invisibly. -- The Phantom Avenger for SE
I have had a small amount of success on occasion writing a mini-language to do something, where the mini-language saved a lot of code. Usually the code was very redundant. Most recently, it was a list of macro calls that made the WindowProc message names clear, whenever there was a macro defined for the message. The mini-languages often looked like your table above. But, rather than arguing that they are "executable specifications", I have been arguing that they are "useful code." Maybe, one theorist's executable specification is a programmer's mini-language?
The software engineering is a young science and there is still a lot to do, but there is already a lot in place and so there is already a lot to learn if you want to work as engineer and not as coder.
You are making assumptions here. 20 years ago, I worked on theorem proving, mostly with resolution-based provers in grad school. I originally believed in things like you say, but I changed my mind. Theory cannot handle the following questions. How do we know that you did not forget a case? What if the user wanted a completely different problem to be solved? How do we know that a hand translation from your diagram to code is correct? These are the hardest questions to answer, and no amount of theory will ever do so. -- The Phantom Avenger for SE
Thowa 10:42, 17 Apr 2005 (UTC)

Last but not least, I found there is an article about formal methods, so it's better to focus on the details there.

I think we agree on this. -- The Phantom Avenger for SE

Thowa 15:09, 10 Apr 2005 (UTC)

POV section snipped

I removed this:

Software engineering is the practice of creating software, productively and with quality.
Members of this profession are called software engineers, programmers, developers, or practitioners.
People who write code and do not follow the doctrines of software engineering are more accurately called programmers, developers, or software artists.

Every one of these sentences is unsupported and debatable opinion. Not one of them is backed by any reference to any source.

First, creating software "productively and with quality" is the goal, not the definition of software engineering. It is a claim that is made by software engineering advocates. Our article on Engineering says "Engineering is the application of science to the needs of humanity. This is accomplished through knowledge, mathematics, and practical experience applied to the design of useful objects or processes." Nothing about productivity or quality there. Would we say that "athletics is the practice of winning games?" Would we say that an athlete is not an athlete when he or she loses?

I agree with your arguments. But, from a historical POV, productivity and quality have been the main drivers of SE for the last 40 years. Fortran, Cobol, Java, code repositories, etc. have all been promoted to improve productivity, quality, or both. The famous "No Silver Bullet" paper was based on the argument that nothing would bring a 10-fold increase in producitivity with 10 years. The main thrust of the CMM is measuring and improving quality (and outsourcing jobs). The SEI in many documents specifically defines SE in terms of process.
The problem is that we have been so busy bootstrapping the SE profession with tools and processes, that we still don't have a "lofty goal" definition of SE. And, I would not trust traditional engineers to write it for SE, or base it on their definition. SE is still figuring out its own reality.

Second, "the doctrines of software engineering" is a very poorly defined term. In fact, "doctrine" and "engineering" are almost antithetical. On page 7 of Sommerville's "Software Engineering", 6th edition, he says:

Engineers make things work. They apply theories, methods and tools where these are appropriate but they use them selectively and always try to discover solutions to problems even when there are no applicable theories and methods to support them.

Are we to say that a software engineer is not being an engineer when he is trying "to discover solutions to problems even when there are no applicable theories of methods?" Or, in fact, is this the time when he is most truly an engineer?

This has always been a point of contention. Is an SE what a typical SE does every day? Is an SE someone who works toward a particular end? With particular tools? etc.... The sentences you removed were written by different authors who insisted that the definition be kept in the article. I at one point moved them into the same section. This text should probably have been removed a long time ago.

Third: Who decides who gets called an "engineer?" On the one hand, very, very, very few people who write software hold a PE certificate. By that definition—the legal definition in many states—very, very few software developers are entitled to be called "engineers." On the other hand, "software engineer" is the job title at many companies for anyone who writes code. It is absurd to say that it is wrong to call someone by their job title. There is no doubt that software engineering advocates would like to define the term themselves, but that is their point of view. Dpbsmith (talk) 23:22, 21 Apr 2005 (UTC)

Once again, an excellent point. Partly this is a debate between the elitists and the populists. Do you have a proposed answer? -- The Phantom Avenger for SE
My proposed answer is to snip the paragraph, since I don't think it says anything useful or important. I don't see any need for it to be there. It is up to those who think something of this sort needs to be there to articulate it in a neutral and non-promotional way. Dpbsmith (talk) 16:21, 25 Apr 2005 (UTC)

Careful about POV: "Profession"

I weasel-worded the statement that software engineering is "a profession." The definition of "profession" varies. Software engineering meets some definitions of profession but not others.

A good example is the existence of a code of ethics. Many, though not all definitions of "profession" say that a professional is bound by a code of ethics, which takes precedence over the professional's responsibility to his employer. It is very clear that medical doctors and their employers acknowledge that doctors are bound to a code of professional ethics. A doctor may be a hospital employee, but is a doctor first and a hospital employee second. The same is true of accountants.

It is far from clear that this is true of software engineers. Dpbsmith (talk) 16:17, 25 Apr 2005 (UTC)


POV

The attempt to remove POV by insisting that software engineering is not a profession and not a form of engineering is extremely POV. If you want to add that most areas do not have legislation establishing a professional software engineer license then that certainly belongs. But I feel no need to stay here and hear how software engineers are not professional, not ethical, not competent, not able, etc. Not licensed maybe, anything else needs to be proved.RJFJR 16:33, Apr 25, 2005 (UTC)

How do you read "regarded by some as a profession" to mean "insisting that it is not a profession?"
If it is important to have the word "profession" in the lead paragraph than it has to be qualified somehow, because some people regard it as a profession, and some do not. It's a grey area. And it depends on how "profession" is defined and people do not agree on the definition. It is clear that software engineering is not a profession in the same way that medicine or accounting is. Does that mean the word profession should not be used? Not necessarily, but there needs to be some care about how it is phrased.
I'd be perfectly happy to leave the word profession out of the lead paragraph altogether. Do you have a wording that you would suggest? Here are some that occur to me: Dpbsmith (talk) 12:09, 26 Apr 2005 (UTC)
  1. Software engineering (SE) is the discipline practiced by software engineers, concerned with creating and maintaining software by applying technologies and practices from computer science, project management, engineering and other fields. [substitute "discipline" for "profession"]
  2. Software engineering (SE) is the practice of creating and maintaining software by the skillful and systematic application of computer science, project management, and engineering knowledge. Dpbsmith (talk) 12:09, 26 Apr 2005 (UTC)
I agree that *not all* agree that SE is a profession. But, from the point of view of simplicity and clarity, saying that "SE is a profession" makes sense. Adding words like "discipline" just make it worse. Just what is a "discipline" or "practice"? Murky words make definitions worse. -- Phantom Avenger for SE
Also, I believe that SE is a profession, just like medicine or accounting. What is the difference? That you need a license? Many people in medicine do not have licenses. Many people in accounting do not have licenses.
As noted above, both medical doctors and accountants subscribe to a formal code of ethics and consider themselves to have a responsibility to their profession and not merely to their employer. An accountant can say to an employer "I can't do that because it is not in accordance with generally accepted accounting principles." I don't think you can point to anything comparable for software engineering. If a doctor said to his or her employer, "I can't do that because it is not medically ethical," the response would probably be an argument for its being ethical. If a software engineer said to his or her employer "I can't do that because it violates the code of software ethics" the response would probably be hysterical laughter. This is a clear difference.
Whoa! Where is it written that "profession" equals "ethics"? I just looked up the definition on dictionary.com [1] and it does not mention ethics. And, "thief" is a very old profession, but where is the ethics in that?
As I have said repeatedly, definitions of "profession" differ. That's what I mean by saying that "software engineering is a profession" embodies a point of view.
It turns out, by the way, that I'm quite right that some people, e.g. the ACM do think that a code of ethics is intrinsic to the idea of a "profession." But it turns out that I'm quite wrong in thinking that software engineering doesn't have one. Here's the IEEE/ACM software engineering code of ethics. So now the question is: is it for real, i.e. is this code of ethics a real part of the day-to-day practice of software engineering? Dpbsmith (talk) 19:51, 26 Apr 2005 (UTC)
Also, the Wikipedia entry for profession hardly mentions ethics. Except that late in the intro, it points out that ethics is less important in the late 20th century.
Of course, if "professional" is taken to mean "someone who is paid" then there is no problem--except that it would imply that most work on open source projects is not software engineering.
None of this should be taken to suggest that software engineers, as a group, are not "ethical." Who can say whether the employees of Microsoft, as a group, are more or less ethical than, say, the employees of Arthur Andersen? I'm just saying that the professions of medicine and accounting formally have an ethical dimension that I don't think software engineering has. Dpbsmith (talk) 17:06, 26 Apr 2005 (UTC)
We know that Arthur Anderson employees engaged in unethical behavior, because AA was put out of business. We know that energy engineers at Enron engaged in unethical behavior, because Enron was put out of business. Their professions did not prevent them from behaving unethically.
And, if we are going to pick nits, what "engineering knowledge" does SE use that is not already covered by CS, PM, or another field like medicine? Many people (like me) argue that SE is not a branch of engineering. For example, the TBP which is the engineering honor society in the U.S. over the last 2 years amended their constitution to ban CS people from joining. Most SE people have CS degrees. Clearly, many traditional engineers argue that SE is not part of engineering. -- Phantom Avenger for SE

IEEE POV?

Replacing the intro paragraph (which is specific) with one defined by the IEEE (which only represents about 5% of the SEs in the U.S. and maybe 1% or 2% of the SEs in the world) is a very political act. That definition certainly does not apply to me or my colleagues. -- The Phantom Avenger for SE

Besides, that definition does not mention ethics. :)

  • OK, what's an organization you like, and how do they define it? My point is not to pick IEEE specifically, but I noticed that a number of other organizations seem to use that definition... and I was looking for an authoritative definition from an outside source that might be accepted as neutral. Dpbsmith (talk) 00:18, 27 Apr 2005 (UTC)
Well I am in the ACM. But most software engineers are not in either organization. Wikipedia in general does not go around using "standard definitions." It tries to create even better definitions. -- PASE

Proposal: Have a Software Development page

Currently, "Software Development" redirects to "Software Engineering". It seems pretty clear to me that not all software development can or should be considered to be software engineering. It might resolve a lot of the POV concerns (on all sides) to have a general Software Development (SD) page that can then direct people to various topics, including Software Engineering (SE), Software Craftsmanship, or whatever. A fair amount of the content should fit within the SD page, while the IEEE stuff can be at home at SE.

Distinguishing between SD and SE might be good idea. Please proceed. Note that there is already a computer programming page.
However, there are many other people who are software engineers who are not in the IEEE. In fact, almost all SE are not members of the IEEE. For example, the ACM has more members who qualify as software engineers than the IEEE does. And, both organizations together cover less than 10% of the software engineers in the U.S. and much less than that around the world. See the Software engineering demographics page for details.
Note that the current page talks about all SEs, and avoids claiming that any one society has the best definition.
If you want to start an "IEEE SE" page, then please start an "IEEE software engineering" page, which can state as much IEEE propoganda as it wants. But, to claim that the IEEE is the primary source of wisdom about SE would be conceited. The IEEE is an important source of info, but they sometimes promote their own agenda, rather than for the whole SE community. -- The Phantom Avenger for SE
I am starting an IEEE software engineering page.

Critical mass

Latest comment: 19 years ago1 comment1 person in discussion

I'm not an expert in software engineering, but I request article critical mass (software) to be written, explaining use of term critical mass in software engineering. A sentence linking to it might look nice after the sentence...

"Many software products contain millions of lines of code that are expected to perform properly in the face of changing conditions."

...in software engineering article. I just can't find the words to write it my self. --80.221.54.251 19:36, 25 May 2005 (UTC)

whooooo

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Software_engineering/Archive_3&oldid=62927997"