Talk:Software engineering/Archive 4

Previous comments

• Talk:Software engineering/Archive 1
• Talk:Software engineering/Archive 2
• Talk:Software engineering/Archive 3

To prepare the article improvement, I have moved the previous talk page to Archive 3. Nevertheless, the whole talk archive (1-3) should be reviewed along with the improvement. --Hans-AC ✉ 15:32, 26 May 2005 (UTC)

 

Question: What is the main similarity between a Software Engineer and a Programmer?

Answer: Neither one graduated from an engineering school

Purpose

Would the paragraph in the entry for "Software Engineering" with the header "Purpose" not be improved by the inclusion of a sentence that begins with "The purpose of software engineering is..."

EN sofware engineer

Does anyone know what "EN" stand for? Thanks

Collaboration of the week??

On May 20, 2005, I proposed Software engineering for the collaboration of the week. I was wrong doing so, because I did not obeye the rule, only nominate articles which don't currently exist or are stubs. Sorry.

Nevertheless, have a look at the comments by ZeWrestler, WB, and Dpbsmith. --Hans-AC ✉ 15:32, 26 May 2005 (UTC)

 

Article improvement drive

Reason

There is a long discussion on the article with a lot of topics not cleared up to now. In my opinion, the article is not state of the art. It could be structured better and some sections could be moved to articles of its own. It should be a start page for all articles concerning with tthe topic and an introductory article for the WikiReader Software Engineering. Simultaneously, I propose a German collaboration (Qualitätsoffensive).

First step: copy to a rework page

I have just copied the whole original article to Software engineering/Rework.

Please feel free

1. to do your proposed changes at first in the Rework instead of the original,
2. to insert any inline comment and include those comments in /* */

/* like this */

Please contribute to the next steps! --Hans-AC ✉ 16:32, 26 May 2005 (UTC)

 

Don't you want to move all this stuff below to the Talk:Software engineering/Rework page? Or has the whole thing just fallen into disarray? Brent 01:47, 18 October 2005 (UTC)

Third step: coordinate Rework with previous discussion topics

... in Archive 1, Archive 2, Archive 3

Fifth step: improve contents

This page could definitely be improved in the front-matter right at the top. Software Engineering, as opposed to the formal discipline of Computer Science, puts much more emphasis on the full-lifecycle of development and (potentially long-term) maintenance of a software product. Whereas most Computer Science-trained folks (those with undergraduate degrees in CS) tend to focus on the programming task -- and Computer Science as a discipline focusses on all the theoretical underpinnings of that task such as algorithm development, language specification, compiler construction, etc.,-- the formal discipline of Software Engineering sees programming as only one aspect of the effective development of a software product. SE looks at Requirements Engineering, Software Design (high-level and low-level), appropriate design notations, test planning, formal Software Validation and Verification, Test Planning, Test execution, and quite importantly, the (oftentimes much longer and for some pieces of software, more costly) Maintenance phase.

Software Engineering thinks about developing and shiping the product that will meet the customer needs, in the required timeframe, and within the specified budget.

The fact that 60% - %80 of software projects (citation: the Chaos Study from the Standish Group) fail to meet one or more of these criteria points up the need for considerable growth and advancement in the discipline of SE.

Aside: the figure of 50 programs granting undergrad degrees sounds way high to me. In 1997 when I formally researched it, there were only four universities granting such degrees (one was Rochester Institute of Technology; I don't recall the others). There are many more graduate programs, but I have no idea the number.

I am sorry I don't have time to edit the article page at present, but I'll try to get back to it in the next few months. The above info is a very quick stab at some needed perspective. --N2e 16:03, 10 April 2006 (UTC)

*whistles innocently*

File:Software development process.jpg

Project2501a 20:36, 24 July 2005 (UTC)

• Cute. This is funny, no doubt, but can someone please explain to me why we have this nonsense in an encyclopædia entry? It is childish at worst and uninformative to the novice at best. Perhaps there could be a section for criticism of the industry as it stands today containing a subsection for humor, but certainly not at the top of the page. It is the first thing that catches the attention of the reader, who is then left wondering what this silly comic has to do with software development. Nevermind that requirements gathering, billing, project scheduling (all of which the cartoon pokes fun at) and so forth are not “software engineering” per se, but are separate practices altogether which support many types of engineering. I apologize for my tone, but I think it is warranted. This is unbecoming of Wikipedia. --MichaelAhlers 15:29, 8 August 2006 (UTC)

Information Quality Management

User:Adrius42 added the following sentence fragment at the end of the first paragraph: A part of an emerging discipline of Information Quality Management. I removed it because it isn't a compelte sentence and the article it points to needs work. Is this term sufficiently common that it should be inserted and if so then where does it go? RJFJR 19:30, August 2, 2005 (UTC)

What is the point of this? It seems to be just like spam.

Source for economic impact paragraph?

Economic

In the U.S., software drove about 1/4 of all increase in GDP during the 1990s (about $90 billion per year), and 1/6 of all productivity growth (efficiency within GDP) during the late 1990s (about $33 billion per year). Software engineering drove $1 trillion of economic and productivity growth over the last decade.

How about a source for this? I thought this was an area of intense debate among economists. The decade mentioned--the 1990s--leads one to ask, in any case, how much was real economic growth and how much was just the Internet bubble. Dpbsmith (talk) 17:19, 5 August 2005 (UTC)

There were articles a few years ago, in both IEEE Computer and ACM Software Engineering Notes, that explained the size of software engineering. Both stated that software engineering accounted for $200 billion to $250 billion in the U.S. of ecomomic activity each year. However it was the federal reserve which stated that "computing" accounted for 1/2 of all economic growth over the late 1990s. Software has 10 times as many people as computer hardware. Software now costs more than hardware. So assuming that software has 1/2 of the impact of computing should be conservative. Just do the math. -- The Phantom Avenger for SE

Process and methodology

Why is it that we have a section called "Process and methodology" and an article called Software development process? Are we not refering to the same thing? --Kim Nevelsteen 20:41, 23 August 2005 (UTC)

The much of the software development process article was originally a section of this (SE) article. It was moved when this SE article got way too long. Then the process and methodology section started growing and changing into what it is today. They cover similar material. I doubt that any effort has been made for them to relate to each other. -- Phantom Avenger for SE

I would propose that maybe a commom article with the exact software development/engineering procedure should be made and that both articles link to it.--Kim Nevelsteen 15:28, 24 August 2005 (UTC)

Sounds good.

What is a software engineer?

I have noticed that a lot of the other articles link to this one under the term a "software engineer". I can understand that software development is now sometimes called software engineering, but what is a software engineer exactly and what makes him different than a programmer, software developer/analyst, Lead programmer, systems architect, project manager? I have personally met people in each of these positions, but I have not met a person that is a software engineer that can state what he does differently than any of the ones I have just stated. At my university there is not a degree for a software engineer, yes one for an industrial engineer and also one for a software developer/analyst, but not a software engineer. To my knowledge it seems to be a title created for those that just feel a little bit better than software developers. Can someone please clarify?--Kim Nevelsteen 15:40, 24 August 2005 (UTC)

The last sentence in the intro section says, "There is extensive debate about what SE is, who qualifies as an SE, who sets the standards, etc." Nobody can give you the definitive answer today, though many people have strong opinions. This is a big problem for this page, because people who advocate one answer sometimes try to impose their favorite answer on this page. -- The Phantom Avenger for SE

It's all quasi-political, quasi-religious.

Some of it is probably related to academic infighting. There were fights when people wanted to establish "computer science" departments at universities—traditionally the stuff had either fallen under "mathematics" or "electrical engineering." How could there be a "science" of computers when computers do not exist in the natural world? Once "computer science" was established, there was then the problem that computer scientists are more interested in studying finite automata or proving theorems about programs than in the nitty-gritty of making million-line payroll programs work, so "software engineering" needed to be invented.

Some of it is an advocacy term. The implication is that there is a set of disciplines and "best practices" which, if followed, will allow armies of average programmers to crank out huge software products that are reliable and can be delivered on-schedule and under budget.

You will notice that the general "tone" of this article is quite different from that of other engineering articles. Dpbsmith (talk) 19:58, 24 August 2005 (UTC)

A software engineer is anyone who says they are one, or alternately, that some authoritative body identifies as one. I don't want a definition of "software engineer" so much as I want a description of what a typical software engineer does. Words have definitions, true, but phrases that refer to some kind of activity (or role) resist abstract definition—just describe the activity! That would provide some idea of what software engineering was. Moreover, one could then write down what a programmer does, and also what a software developer does, and compare them and see if anything comes of it (like, they're all the same, or that some go to more meetings, or something). There is definitely a lot of commonality in the effort of creating software, regardless the nomenclature, since a lot of software gets created, and mostly in similar ways. Brent 02:06, 18 October 2005 (UTC)

Although I happen agree that "a lot of software gets created, and mostly in similar ways," I believe those who use "software engineering" as an advocacy term would strongly disagree. They would assert (incorrectly) that there is a difference in kind between the sort of creative art/craft small-team-of-bright-individual programming that produced e.g. the original Mac OS and what SEI CMM 5 organizations do. Dpbsmith (talk) 09:36, 18 October 2005 (UTC)

In which case, documenting the controversy about software engineering is more important to the Wikipedia than trying to resolve it. But I challenge any software engineer to deny that you'd have engineered software without programmers writing code and compilers compiling it. I personally don't think that software engineering is different in kind, only in degree, but maybe even that's moot.

So, how about an article with this gist: "Software engineers make software. What makes them different from other people who make software is subject to vociferous debate. Some people think software engineering is a loaded term. Some think it is an oxy-moron (or just nonsense). Others (X number of self-described software engineers amongst them) think it's an important and valid distinction. Many have said that software errors are bad, and that something needs to be done to avoid them. It seems to be taken for granted that making software gets harder the more complex it is (exponentially so?), so highly managed techniques are an attractive way to attempt to control the complexity. Pro-software engineering camps favour systematic approaches in line with other engineering disciplines, as well as similar accreditation and the like. See other articles for different opinions about how to increase software quality/reliability." 216.234.42.2 20:41, 18 October 2005 (UTC)

Well, I like it. I trust you can dig up source citations to show that there are camps holding each of those opinions... I just noticed that SEI now disowns the entire CMM model and has a New Improved model. I'll bet the organizations that spent good money getting to CMM Level 5 are really pleased to know that their certifications are garbage and it's time to hire a consulting to help them qualify for CMMI certification... :-) Dpbsmith (talk) 22:31, 18 October 2005 (UTC)

For Wikipedia internal consistency, if this article is to remain entitled "Software Engineer" it could read like and perhaps even reference the Wikipedia "Engineer" article. The "Engineer" article currently states, "An engineer is... a person who uses scientific knowledge to solve practical problems using technology." If it is postulated here that "Software Engineer" is a specific example of the general category "Engineer" in the same manner that "Automotive Engineer" is a specific example of "Engineer" then the difference between "engineer" and "builder" becomes somewhat clearer.

According to this definition, what distinguishes a "software engineer" from a "software developer" is the application of "scientific knowledge". Scientific knowledge is that type of knowledge that is measureable, repeatable, public (published), peer reviewed, and accepted as fact, or at least factually backed theory. I can personally build a car (or dune buggy, or at least a go-cart) by going into a scrapyard and sort of copying what I see. I can probably build it faster and cheaper than a regular car. Furthermore, there is certainly nothing wrong with building a go-cart for private use, and there should never be any legal restrictions on doing so. It may be a fine vehicle, even a thing of beauty - but it likely wouldn't be generally accepted as being "engineered" and legally roadworthy. In contrast, I could read a large body of knowledge on car design, and perhaps even get certified in that BOK, which may be time consuming and annoying and indicate some commitment to a long-term career in that field. I also then have to commit to following generally accepted scientific principles regarding effective automobile construction that meets specifications including socially accepted codes for safety, comfort, limits on permissable uses of toxic materials, acceptable stopping distances etc etc. Complete overkill for a go-cart. Not entirely necessary for the dune buggy that me and my buddies are going to run in off-road settings. Completely legitimate if human safety, large volume sales, and/or a business is at stake.

The gist for me then is not whether there is a role called "software engineering" - but rather "is software engineering a common practice, or more of an exception"? I don't know the answer to this, but I know I want to fly in planes where the engine control software was "engineered". I want to do my banking with software that was "engineered". I don't care if thousands of people write tons of cool programs for tons of cool purposes and even distribute them for free. That's probably even a good thing. Especially if it's a cool game. But if that cool free game bungs up my home computer, then I'll be mad anyway, even if its free.

I hope my little diatribe sheds some light on the above comments and implied questions as well, particularly the initial para by K. Nevelsteen. ThreePD

Slightly related, I am curious to know which software engineering methods have been used with the Linux development model [section Software engineering today]. Traditional software engineering methods have emphasized the importance of specifications/requirements documents, but the Linux project has been able to deliver a solid piece of software without the use of these. If the software engineering methods used by Linux is documented somewhere, it would be helpful for future projects, especially open source ones.

I am a software engineer, The difference is simple, i have a degree on my wall that says software engineer. Those who have an engineering degree are engineers. you can't be an engineer without an engineering degree from a university. let me give some examples. a construction worker is not a civil engineer. a construction worker with 10 years of experience may know more than a new grad civil engineer. but the construction worker is still NOT a civil engineer. if you have an engineering degree your an engineer, otherwise your are not. an electritian is not an electrical engineer. an electrician with experience can know more than an electrical engineer. but the electrician is NOT an electrical engineer. a factory supervisor can know more than an industrial engineer, but he is still NOT an industrial engineer. there are many more examples from every engineering discipline. and more. hope that helps. the difference in the job they do doesn't matter, anyone can do anyone's job with enough practice. if you see a Surgeon do an operation 50 times, you will be able to do it yourself. does that make you a doctor? clearly NOT you have to go through med school first.

Okay... and what about a Software Quality Engineer?? This new term that has come up in the IT industry -- is a Quality Engineer also a Software Engineer? --221.134.24.63 19:36, 21 May 2006 (UTC)

I'm one of those guys writing "Software Engineer" as profession. what's the difference? why do i use this term? It's quite similar to the difference between a construction worker and the architect. even with years of experience the first one will be able to build you a good wall, but letting him build a bridge will get him to his limits. missing knowledge about scientific methods like statics. and the architect will most probably not have the ability to build you a nice wall (even with years of experience), but with his science background he will be able to plan and (hopefully) also supervise the building of large constructions. he will even be able to tell you in advance if the construction will sustain heavy storms. because he knows the numbers. while the construction worker will tell you by experience for his wall if it is strong enough for certain strains. Additionaly the REAL BIG DIFFERENCE is: the architect (at least here in Switzerland) has by law to take responsibility for his construction!!! So for simple software the software engineer is often not evidently superior to a programmer, but when the problem gets larger (and we engineer defend our jobs with the story "most software grows with time and gets larger than ever expected") the programmer ends up with a limit of complexity he can manage. the engineer is prepared to see problems in algorithms sooner and should use more appropriate ones, while the programmer leak of knowledge leaves him clueless. so far in theory, but there is also experience and the difference in quality of studies. Saw already a certified informatic engineer going through the same studies like me and having a quite blurred knowledge about object-orientation and others with such degrees writing very bad code. in practice software engineer studies should give you a very precious scientific background to recognize problems earlier, simply because you know them! a construction builder will not see statics problems because he simply does not know them, but learns it in practice, step by step and most probably not reaching the amount of knowledge, the architect learned by studying statics models. This is simply a transfer of knowledge build up in decades or centuries from earlier constructors/architects.
But still: Universities give you a distilled knowledge about the topic from experience of your predecessors, but those studies are only fruitful with practice! finally with practice/experience you can apply this knowledge. in software engineering i would say: yes, it is superior, but without practice it stays theory and who wants a theoretician?
So i use this term to distinct myself with one point: engineer means "responsible body", i am aware of and taking the responsibility for the task, not just "executing commands" and being one of the construction workers. why? because i can estimate the effort and problems by having the scientific knowledge AND experience. The university degree usually asserts the former, but only with addition of the latter you get what i respect as a real software engineer. Too bad often people use this phrase just because of their studies.
So i disagree that by default a software engineer is better than a programmer, just agree that he has also the scientific knowledge, but only with experience he gets better and able to take the responsibility.
So you could do a doctor's work after having seen the operation 50 times, but without the title you will not be able to take the responsiblity, because if somethings fails during the operation, you are mostly clueless, you can only reproduce the steps you saw. why he did it or what you have to do now because something failed? you don't know. by knowing how the human body works, you can estimate what merely went wrong, you are "prepared" for deviations from standard proceeding, you get in sich situations on your own and have to take decisions. got it? the construction worker could try to build it, but on problems beyond his scope he's clueless, like you as a doctor replacement. while the doctor and the architect know the models of human body resp. statics and can estimate what's going wrong, see first signs and take decisions to avoid those problems because they happen.
same for the engineer, building a software he should see issues about security and performance, because of his scientific know-how. the programmer can build something that runs, but if without the know-how he will not even be able to see security or performance issues in his product, while an engineer (with experience) may see it at once and take decisions before the issues turn up in production... (User:anonymous, 15:00, 4 April 2007 (CET)) My opinion is that SE is not yet a mature discipline. There are still too many semantic gaps when moving from goals to business requirements to system requirements to etc. ... to code. What is msiing is the rigour of translating the conceptual design (and rigorously designing the conceptual design) eventually to code with minimal semantic loss. This implies that the design itself should be mostly semantically complete and specified in some standard 'engineering' languages (/models). I realise that much work still needs to be put into software generation, architecture designs, automating requirements engineering/tracking/validation, business process specification standards, etc. Not to mention bring all of these together so that software can be built (or generated) as designed. It is this rigorous design that I would consider as being Software Engineering. It all starts with requirements practices and 'engineering' the necessary metamodels and ontologies that will deliver the required knowledge bases and requirements models that will drive software design. MetaAnalyst 09:02, 12 July 2007 (UTC)

I added a {{seemain|Controversies over the term Engineer}}. I think it is relevent and can clear up a few {{fact}} tags in this article, I am just not positive I placed it in the correct location. Exit2DOS2000^•T•C• 20:09, 28 September 2007 (UTC)

Relationship to (Dependency On?) Definition of Computer Software

Hi. I'm a trifle concerned (and amazed) that so much energy is expended on arguments about "Software Engineer" when one of the operative terms—Software—has an article on Wikipedia which is so wanting. It seems obvious—if only to me—that it's very difficult to define a term like "Software Engineer" without first getting an explicit consensus on the nature of software. I guess it's just too obvious to everyone else. Even if I'm off base, that page needs attention, and maybe it would be a good day off for some of the participants around here. And if the nature of software is so obvious, it's a shame that the page is so poor, since it would be a low-hanging fruit.

The weird irony is that instead of paying sufficient attention to a discussion of software, a lot of energy has seemed to go into creating a long list of kinds of software. Are software engineers feeling so slighted that they feel a desperate need to advertise? I've never found lists of examples of a type did much to explain the deeper nature of the type. And with something like software, where the end product is only the tip of a very large iceberg (hence the energy expenditure to understand and describe the act of its creation), the futility of such a list is even more pointed. A proper definition deserves better attention in the Wikipedia.

A while back I added a bunch of stuff to the Talk:Computer software page, hoping it would attract some more attention. I have ideas about what to do, but I'm new at this and can only drop in periodically, so I could use some help.Brent 01:11, 18 October 2005 (UTC)

Please avoid the mistake of confusing a concept with the words and letters that describe the concept. For example "engineering" is not "enginee" + "ring" which might be the interpreted as "engines that make rings" or something else silly. There are not a lot of rings in most engineering. Likewise, "software engineering" is not "software" + "engineering". SE almost never uses differential equations, or phyics or chemistry. And SE is not just a fancy version of software. Software engineering is its own field, with its own history, ideals, tools, conventions, etc. That is why this article struggles so hard to define itself. -- Phantom Avenger for SE

Computer hardware engineering doesn't necessarily make heavy use of differential equations, physics, or chemistry either (unless you're talking about low-level semiconductor device design). They're more likely to use boolean algebra and other discrete formalisms. By the same token, there are many aspects of signal processing (nominally an electrical engineering discipline) that make minimal use of differential equations or chemistry. Engineering is not defined by differential equations (even if many engineering math textbooks might lead you to believe otherwise), or continuous mathematics in general. Nor is it defined by a tie to physics or chemistry. Engineering is a pragmatic approach to solving design problems.

The reason that SE seems different from other engineering disciplines is that other engineers (pragmatically) use appropriate mathematics and scientific results to understand what their designs will do before integration and test time, while many self-professed "software engineers" are loathe to use any form of mathematics and restrict their use of science to experimentation with different implementations to find something that will work. Which is not to say that there aren't developers that actually "engineer" their software (e.g. by using CSP to evaluate a design for deadlock prior to committing to implementation, or performing some prototyping so that they can make throughput measurements that can be extrapolated to a finished system, or using relational database theory to help them develop a good design). They're apparently just somewhat rare. --Allan McInnes (talk) 22:19, 2 March 2006 (UTC)

If software engineering was so close to traditional engineering, like you say, then companies would gladly hire civil engineers or mechanical engineers to do their programming and software project management. But, companies don't, because software has almost nothing to do with engineering. Rather, companies hire computer science and IT and all sorts of other professions to do programming and project management, because that is what software engineering really is.

The reason software engineering don't use a lot of math, is because the logic and deduction that they use every day is not considered real math by engineering snobs. And software engineers don't use calculus or physics, like engineering snobs. -- The Phantom Avenger for SE

By your logic, electrical engineering apparently isn't engineering either, since few companies are likely to hire a civil engineer to do analog circuit design and microprocessor design project management. Yet EE is engineering, jsut as SE is engineering. What makes all of these things engineering are shared underlying principles related to how to solve problems and how to design things. What separates them is domain knowledge.

There are a number of reasons that companies hire people other than software engineers to do their programming. Among those reasons are: CS grads have the requisite domain knowledge, and nominally learn some engineering design principles; engineering encompasses more than just programming and all the company needs is programming; some companies don't need (or don't realize that they need) software to be engineered – any random hack that works will be acceptable.

Any "engineering snob" that thinks that the math behind software engineering isn't "real math" has apparently never encountered category theory, type theory, process calculus, or algebraic specification. And I say that as a trained engineer (EE and Aerospace Eng. degrees). --Allan McInnes (talk) 21:23, 5 March 2006 (UTC)

I have spent almost my entire life in software and software engineering, and I am still amazed at how often EE and aerospace engineers try to tell me what my job is. Usually, it is related to a statement about "engineers do this, so software engineers should do it to." For example, the CACM published an article recently about how when software engineers finally get "real engineering practices" there will be no more cost overruns in software projects. Also, the Tau Beta Pi passed a constitional ammendment stating clearly that CS is not adequate to join their engineering honor society. This says as a loud as possible that I am not an engineer, even though I am an SE. The Tau Beta Pi is full of engineering snobs. —Preceding unsigned comment added by 204.134.9.4 (talk • contribs)

Well, I'm sorry if you've had bad experiences with engineers from other disciplines who do not understand sofwtare engineering. All I can tell you is that, having been educated as an engineer, and worked in both software engineering and other engineering fields, I see a lot of similarities in approach but an obvious need for differences in analysis tools. IMHO software engineering is as much engineering as any other engineering discipline (whether or not every "software engineer" uses good engineering practices is a separate question). I'm not alone in this: software engineering luminaries such as David Parnas and Steve McConnell also hold this view. The fact that the IEEE publishes a Transactions on Software Engineering would seem to indicate that the IEEE feels the same way.

I've recently been working my way through The Pragmatic Programmer again, and am constantly struck by how much of the content is great advice for practicing engineers in any discipline (I wish someone would write The Pragmatic Electrical Engineer in the same style and with similar content). But then I guess that shouldn't be surprising, since engineering is fundamentally just "pragmatic design of useful products". --Allan McInnes (talk) 21:33, 9 March 2006 (UTC)

The question is not whether there are similarities, of course there are. There are also many differences. There are also similarities to creative writing.

The more interesting thing is that there are almost as many software engineers as there are traditional engineers combined. Software engineering is a big, important, long-lived pofession, that does not need to be defined in terms of traditional engineering. The people who seem to claim SE as engineering mostly seem to be wannabes, who disrespect the legacy of software engineering. There are over 10 times as many software engineers as computer engineers. We don't need CEs or EEs telling us what SE is all about. We don't need your condescension. - Phantom Avenger for SE

Sure. But there are also differences between other engineering disciplines. It's the similarities that make them all "engineering". And yes, there are undoubtedly, at a more abstract level, similarities between every kind of creative endeavour. That doesn't change the fact that "engineering" (regardless of the discipline) has certain common concerns that are not shared with other creative endeavours.

I wouldn't call David Parnas a "wannabe" who "disrespects the legacy of software engineering" — he helped create a lot of the legacy to which you are referring. So I'm not quite sure what you're trying to get at there.

I'm also not sure why you are trying to create some kind of artificial dichotomy between "software engineering" and "traditional engineering". For starters, there isn't really any such thing as "traditional engineering". There are some traditional disciplinary divisions, but even those are hazy (many control engineers come from an ME background, many others come from an EE background), and the field is constantly evolving (disciplines like aerospace engineering and computer engineering are not all that much older than software engineering, and disciplines like biomedical engineering and nanoengineering certainly post-date SE). As I've said several times now, it is the commonalities between all of these disciplines that makes them all "engineering", and suggests that there may be knowledge and principles that can be usefully shared between them. That was certainly the rationale for the naming of the 1968 NATO Software Engineering conference that helped popularize the term "software engineering". If you don't believe that SE has anything in common with other engineering disciplines then I have to wonder why you insist on calling it software engineering (as opposed to software development or some other term that doesn't connote a relationship with engineering).

Having said all of that: the debate about what SE actually is has been going on for decades (as this article makes quite clear), and the odds of us resolving the argument here seem pretty minimal. Not to mention taht it's not really what talk pages are meant to be used for. So, thank you for discussing this issue with me, and please don't be offended if I don't participate any further in the discussion. --Allan McInnes (talk) 01:27, 10 March 2006 (UTC)

There are similarities and differences. However, I did not choose the word engineering, nor did I choose the things I actually do on the job. These things emerged on their own. But, software engineering is still completely from engineering, as the Tau Beta Pi, the National Academy of Engineering, and other traditional engineering organization prove everyday, by deliberately slandering computer science and software engineering. I did not start this. Traditional engineers did.

I note that you end up by saying "If you don't believe that SE has anything in common with other engineering disciplines then I have to wonder why you insist on calling it software engineering" which is analyzing a field by the words, and not by the reality. This is typical for engineering, but poor analysis. -- The Phantom Avenger for SE

I noticed that the article argues that Dijkstra considered software engineering to be a branch of mathematics. I disagree. In 1989 Dijkstra called SE "The Doomed Discipline", and he wrote that SE has accepted as its charter, "how to program if you cannot" (Dijkstra, Edsger W. (1989) On the Cruelty of Really Teaching Computer Science. Communications of the ACM 32(12): pp.1398-1404). Dijkstra considered computing science to be a branch of mathematics --Matti 10:02, 10 July 2006 (UTC)

Software engineering vs software architecture vs software design?

I hate to sound like a pedant, but can anyone shed light on the relationship (if any) between the following disciplines (or are they practices?):

• Software engineering
• Software architecture
• Software design

--Richard@lbrc.org 17:07, 3 January 2006 (UTC)

Answers to questions of life, the universe, and software engineering

Sure, at the risk of near certain critique, I'll give it a whirl - but from a bottom up perspective, and including the more foundational term you avoided in this recurring list.

• "Software programming" indicates an activity of forming a software program which means producing at least some piece of a special syntax language (code) that can provide instructions to a computer. Several different languages and techniques are available.
• "Software design", in contrast, indicates an activity of designing, which means forming an arrangement of software components that fulfils some specific purposes. It implies that the software program has achieved a degree of complexity that warrants decomposition into smaller "blocks" or "modules" that require arrangement. This deliberate arrangement attempts to achieve some of its own purposes that are commonly known as design criteria or non-functional requirements, such as safety, performance, maintainability, or simply aesthetics. Preferably there is a documented artefact that describes the "arrangement" and how well it meets its design criteria.
• "Software architecture" is often misunderstood as high level software design, but it actually represents the overall approach taken to the design activity (for example following a multi-threaded distributed task architecture with priority pre-emptive scheduling). These top-level architectural decisions inform the design at every layer of abstraction and must be consistently applied within the intended scope in order to achieve the desired end-results. For example "Baroque" is quite a different building architecture than "Multi-unit efficiency", although each has its own merits and schools of designers. Designs are specific manifestations of those architectures. I can speak about a software architecture without pointing to a particular design.
• "Software engineering" is an engineering discipline that seeks to study the sciences and technologies involved with the practical development of software in order to better apply those sciences and technologies towards greater success. Software engineering includes the practice of defining important terms and relationships between terms (forming relevent ontologies), as well as discussing the merits of the various architectures, designs, and programming languages and techniques that are available. The idea is to form a publically available Body of Knowledge (BOK) about the discipline. There are of course various schools of thought within this BOK. Correct application of software engineering generally depends on possessing detailed knowledge about both the available techniques and the domain area under consideration. The debate about the nature of the SWE BOK (software engineering body of knowledge) is part of the BOK itself. This is also the case for any discipline including philosophy and history.

ThreePD 21:24, 4 February 2006 (UTC)

My over-simplified perspective:

• Software programming - Writing code. Flow-charting would not be considered programming, but programmers may develop and use flow-charts.
• Software design - Developing specs, planning and problem-solving for artistic form and user-interface experience (both predictable and subjective). Designs may or may not include engineering.
• Software architecture - Planning and problem-solving (including flowcharts) for the broader computing structure of code-driven functions based on design specs.
• Software engineering - Planning and problem-solving (including flowcharts and code) for all computing structure, code-driven functions and scientifically predictable user-interface experience based on design specs.

That's just my take. But since I'm none of the above, I may be wrong. I'm only posting this because anyone concerned needs to know how it may appear from the outside looking in. It is just one perspective. Oicumayberight 22:23, 26 October 2006 (UTC)

Hello i'm a master in Computer Science and i would say: Software engineering is a problem solving activity that solves problems with software. This will result in a software architecture, or if you would like: the software design. ( design of the system en the architecture of the system are just equal, only in the cs community we are using the term 'architecture' more often ). Software programming is the actual work that implements your architecture/design.

Just like laying the bricks to build a building ( the bricks must follow the architecture of that building).

TjerkWol 22:20, 14 February 2007 (UTC)

Since design is a process as well as a product of that process, where do you make distinction between design and engineering? Oicumayberight 22:28, 14 February 2007 (UTC)

well i see design only as a product. Software engineering also involves design ( as a process) but it involves more, like requiremetns gathering and software testing. TjerkWol 14:19, 27 March 2007 (UTC)14:19, 27 March 2007 (UTC)

Designers gather requirements and test solutions too, just not in every case. Oicumayberight 18:19, 27 March 2007 (UTC)

State of the ART

I would like to give a presentation on a new topic in SE , any suggestions ? Thanks

Education

Someone keeps modifying the description of Software degrees in the education section to say that

About half of all practitioners today have computer science degrees with detailed knowledge of hardware.

AFAIK, the majority of CS programs do not teach "detailed knowledge of hardware" - hence the term "software degree". Can whoever keeps making this modification provide some kind of evidence that

1. There are a significant number of CS degrees that teach "detailed knowledge of hardware".
2. That about half of all SE practitioners have received such degrees.

--Allan McInnes (talk) 14:49, 12 April 2006 (UTC)

Reference, please?

I would really appreciate a citation for the statistic stating that the Boeing 777 has X many processors and 5 million lines of code. I happened to find the statistic "2.5 million lines of code" in a CMU article (http://www.sei.cmu.edu/str/descriptions/ada83_body.html), but that author was citing someone else, using URLs that (when I checked) were dead. Anyway, it would be nice to have a source for this quote, because I'd like to believe it and I'd like to use it in some presentations. -- LandruBek 11:09, 20 April 2006 (UTC)

I don't know where the previous material came from. Unfortunately I mistook the reason for your query. In the context of the article, believing that facts should be sourced, I replaced the unsourced statement with a different one--properly sourced--to the effect that an airliner has several million parts, and the space shuttle has ten million. The two point here is that software is roughly comparable in complexity to the most complex physical objects.

The unsourced sentence I removed was:

(The Boeing 777-200 has about 132,500 engineered and unique parts. Including rivets, bolts and other fasteners, the airplane has more than 3 million parts. Included are approximately 1400 data processing units and 5 million lines of code.)

Dpbsmith (talk) 15:22, 20 April 2006 (UTC)

I too have no idea where the previous data came from. However, I've added a sourced SLOC count of 4 million lines of code for the Boeing 777. This comes from a CrossTalk article written by Boeing's Manager of Embedded SE for the Commercial Airplane Group. The actual breakout is (from the article) ~2.5 MSLOC of new code, and ~4 MSLOC inclduing COTS and optional software. I have no idea how many processors the 777 has though. --Allan McInnes (talk) 17:11, 20 April 2006 (UTC)

Unsourced material about economic impact

The material below has been unsourced for a long time. It shouldn't be in the article unless there is a source. (And, saying "reliable statistics are hard to find" is not a substitute for finding them!) Dpbsmith (talk) 16:27, 16 May 2006 (UTC)

Material removed:

Economic: In the U.S., software drove about one quarter of all increase in GDP during the 1990s (about $90 billion per year), and one sixth of all productivity growth (efficiency within GDP) during the late 1990s (about $33 billion per year). Software engineering drove $1 trillion of economic and productivity growth over the last decade. Around the world, software drives economic growth in similar ways, though reliable statistics are hard to find.

An anonymous user reinserted the above text, and added a "source" for the statistics. However, after looking at the source in question (Raccoon, L. B. 2001. Definitions and demographics. SIGSOFT Softw. Eng. Notes 26, 1 (Jan. 2001), 82-91. DOI= http://doi.acm.org/10.1145/505894.505914), I have again removed the text in question. The article by Raccoon does not support the text in any way, and in fact does not appear to contain any mention of GDP or economic growth.

I have also again removed the "peacock statement" on social impact that was reinserted after Dpbsmith removed it. Dpbsmith is right: this is a vacuous "peacock statement". Nor has any source been provided for this statement. --Allan McInnes (talk) 19:13, 17 May 2006 (UTC)

#1 on Google

Wikipedia is now (finally) the standard authority for information on software engineering. I just searched on Google for "Software engineering" and this page for the first time (that I have ever noticed) came up in the #1 slot. Note that most other search engines did this long ago. —Preceding unsigned comment added by 216.184.31.126 (talk • contribs)

Applications or Systems?

The first sentence says that SEs write "systems" when it used to say "applications". I find that system is a blah word that refers to complex things of unspecified nature. Application is far more concrete. SEs write word processors, but are word processors systems? Is a video game a system? Is a flight control application a system? The answer is partly yes, but seems so unsatisfactory. I think it should be reverted. -- Phantom Avenger for SE

Are you suggesting that SEs don't write, for example, operating systems? Or is it your contention that an OS is an application? --Allan McInnes (talk) 17:21, 14 July 2006 (UTC)

For my money, dump the word system and leave it as "... create and maintain software by applying ...". A software engineer can engineer software components without ever producing something that would be called a system. For example, a library developer, etc. -- Munchtipq

Works for me. --Allan McInnes (talk) 14:36, 7 August 2006 (UTC)

Pervasiveness in missions requiring 'absolute' reliability

Re that statement, I meant not that software is often found -- as an essential component-- in missions requiring high reliability (my claw hammer has no software), but rather that software often finds itself in such situations. That idea is so pervasive that I would think a citation is not needed. Providing one would be low priority for me (unless I come across one by good chance). Anyone feel free to revise, revert or provide cite. Vincehk 03:09, 27 August 2006 (UTC)

If the idea is so pervasive, then it should be easily verifiable :-) --Allan McInnes (talk) 14:57, 27 August 2006 (UTC)

add'l comments

It might be useful to reference the SWEBOK effort, including Notkin, Gorlick, and Shaw's dissent:

 http://www.acm.org/serving/se_policy/bok_assessment.pdf#search=%22swebok%20shaw%22

gotta mention CMU SEI's CMM.

Advocacy definition

It looks to me as if the "advocacy" definition of software engineering was there before the IEEE definition was added. I thing the IEEE definition should have replaced the advocacy definition, since it is exactly what was being advocated; i.e. "software engineering" did not refer to the advocacy itself but rather to what was being advocated. I would therefore suggest deleting the advocacy definition, but I didn't want to do that without checking, after someone had gone to the effort of finding a citation. --Boson 17:51, 19 October 2006 (UTC)

Questions from the jury

Is there any part of the software development process that is neither administrative or engineering? Oicumayberight 22:39, 24 October 2006 (UTC)

The easy answer is that programming is neither "administrative" nor "engineering". (The whole point of "software engineering" is to make programs.) According to people like Dijkstra, writing programs is more like mathematics than anything else. The hard answer is that there is a huge debate over what "engineering" means and how it applies to "software". This page details some of the debates. Then, of course things like "requirements analysis" and "testing" apply to many fields beyond SE and engineering, so depending on point of view, they may not be either. -- Phantom Avenger for SE

Next question: Should everything that attempts to accomplish anything be called engineering? Would it be accurate to call parenting or spousehood, "family engineering?" Oicumayberight 21:24, 26 October 2006 (UTC)

I would say that the term "engineering", in its literal sense, can only be applied when the main product of the process is the result of significant intelligent design by persons, even though the process may also involve activities involving humans rather than artificial objects. This would apply to machines, computer hardware and software, probably even bridges, roads and buildings, though all involve application of theories and methods, project management, definition of processes, getting things to work, etc. It would apply particularly if the product functions or operates in a way that has been specified in detail by humans (like a nuclear reactor or the software used to control it). In an extended sense, the term "engineering" could also be applied to biological systems if they are deliberately manipulated on the basis of defined methods and theories (e.g. "genetic engineering"). --Boson 23:16, 26 October 2006 (UTC)

Would this mean that work to achieve indefinite (open-ended) goals and expectations would fall under the category of "art" not engineering? Oicumayberight 00:12, 27 October 2006 (UTC)

I don't see that the goal (rather than the immediate function) is particularly relevant, but I may have misunderstood. I suppose one might draw a distinction between civil engineering and architecture based on the relative importance of operation or functionaity, rather than aesthetics, if that is what you mean.

Your question is a good one, which is very, very hard to answer. There are lots of debates over *how* to define "engineering". It might be a tradition, a guild, an ideal, etc. This page details some of the complexities, as far as software is concerned. But, I don't know of any way to give a definative answer. -- Phantom Avenger for SE —The preceding unsigned comment was added by 216.184.13.211 (talk • contribs) 00:15, 31 October 2006 (UTC)

images

Image:Software spanner.png is a nice picture, but it is not informational and adds no information to the article. It only adds some aesthetic value. Can we find a picture that adds both aethetics and useful information? NerdyNSK 21:05, 28 October 2006 (UTC)

"Very few traditional engineers bother with any form of certification"

I'm removing

Others point out that very few traditional engineers bother with any form of certification.

because it's nonsense. See Professional Engineer and National Society of Professional Engineers.

50,000 credentialed professonal engineers in the United States is not "very few."

In many states in the United States it is not even legal to advertise yourself as an "engineer" unless you hold a PE certificate. Dpbsmith (talk) 18:20, 1 December 2006 (UTC)

While I'm not defending the statement you removed (it's unreferenced opinion), it's worth noting that the truth of the statement largely depends on what you mean by "traditional engineer" (which IMHO is a worthless term - but that's another argument). While PE certification is certainly popular (or even mandatory) in certain engineering disciplines, it gets hardly any attention in others. I've worked as an engineer in the space industry, and few of the engineers I knew there bothered to become a PE. The same goes for a lot of the electrical and embedded engineers I know in my current line of work. Having a PE is helpful in situations where (a) public safety impacts of the product are a concern (e.g. civil structures) and you need to be able to legally sign off on having met safety requirements, or (b) you want to have legal standing to testify as an expert witness. Things like satellites and consumer electronics generally don't have the kind of public safety requirements that necessitate a PE, and so a lot of engineers in those fields don't bother to get a PE. The BLS occupational employment stats for 2005 show over 1.4M people employed as engineers in the US, which means that the 50,000 credentialed PEs amount to less than 4% of engineers. Of course, many of those 1.4M engineers may not be "traditional engineers", since I'm not sure if things like biomedical engineering or environmental engineering count as "traditional". Perhaps I'm not a "traditional engineer" either - are satellites or wireless sensor networks "traditional" engineering products? --Allan McInnes (talk) 03:25, 2 December 2006 (UTC)

Good point. Taken. Dpbsmith (talk) 03:03, 3 December 2006 (UTC)

P. S. Of course, if our article is correct in saying "Software is often found in products and situations where very high reliability is expected, even under demanding conditions, such as monitoring and controlling nuclear power plants, or keeping a modern airliner aloft" then software is "often" found in places where public safety impacts of the product are a concern ... Dpbsmith (talk) 03:03, 3 December 2006 (UTC)

Indeed. Yet software is "often" found in a lot of places. I think I understand what the writer was trying to get across with that statement, but it strikes me as a rather poor rationale for software engineering as a whole - the high-reliability, safety-critical side of software development is something of a niche area. Many other kinds of (non-software) products which are not safety-critical are engineered, so I don't think that the safety-critical nature of a product is a necessary condition for engineering the product.

The other issue is that PE licensure is (at least in the US) a requirement only in performing work that a state regulates. Safety-critical software does not seem to fall into that category. I assume that things like commercial aircraft and nuclear power plants are subject to federal regulation. Since there's no federal PE license, they presumably have other methods of assigning legal responsibility for the performance of the prodcut (although I haven't worked in those areas, so I don't know for certain). --Allan McInnes (talk) 18:26, 3 December 2006 (UTC)

The statement "very few" is obviously misleading. About 1/3 of all civil engineers have licenses. But, excluding civil, electical, and mechanical, probably at most 5% of practicing engineers have licenses.

People talk ad nauseum about "public safety", but only a tiny fraction of aerospace or nuclear or automotive engineers have licenses. And automobiles are the leading preventable cause of death in modern societies. When was the last time you heard about an automobile engineer being sued over a death or global warming? The issues are very complex, but suffice it to say that for most people corporations are the boundaries of responsibility, not licenses. The people who advocate licenses for software engineers too often talk about the mythology the civil engineering rather than the reality of all engineering. -- The Phantom Avenger for SE. —The preceding unsigned comment was added by 69.49.173.16 (talk) 20:30, 14 February 2007 (UTC).

Criticism of software engineering

That article doesn't read like an encyclopedia entry, it reads like a promotional pamphlet. I tagged it both for failing to establish notability and lacking any sources for the criticisms. I am not planning to blank it or propose it for deletion, but it really could use a lot of improvement. CMummert · talk 16:52, 26 January 2007 (UTC)

It seems as if it is a POV fork from this article. Should they be merged? Blueboar 23:08, 27 January 2007 (UTC)

If sources can be found for some of the criticisms and responses, then they could (and probably should) be merged into this article. The same could be said for the articles Comparison of software engineering and related fields, and Debates within software engineering, both of which unsourced, and somewhat redundant with material already in this article. --Allan McInnes (talk) 02:29, 28 January 2007 (UTC)

If the article doesn't cite sources, and is duplicative of other articles, then shouldn't it be put up for AfD? I popped into this article because of a comment at the Village Pump, which calls into question the idea of having "criticisms of... " articles. I tend to agree. Either merge the material or delet it. Blueboar 03:30, 28 January 2007 (UTC)

That article was historical. The original content of the "software engineering" article was a long list of complaints about SE. I added the refutations, because a list of complaints does not make a good article either, and nobody would let any individual complaints be dropped. Later, when the SE article got too large, it was chopped into pieces, and thus was born the criticisms article.

The problem remains. Most of the criticisms of SE remain valid, though one can debate forever, how much they matter. Documenting the list is valid, at least for historical reference. But, how much of each side should be represented? Now that the SE article has been stable for a couple years, some of the sub articles (such as criticisms) can probably be dropped. -- The Phantom Avenger for SE. —The preceding unsigned comment was added by 69.49.173.16 (talk) 20:20, 14 February 2007 (UTC).

Contradictory leader

The leader begins with a (unreferenced) flat assertion that "Software Engineering is..." A little bit further down, it lists four different interpretations of what "software engineering is". This seems a little contradictory. Any suggestions on how to resolve this contradiction? --Allan McInnes (talk) 03:42, 2 February 2007 (UTC)

Longish reply

I think we should replace the first sentence with a concise definition based on the IEEE definition. This gives us a verifiable definition by an authoritative body. Alternatively, or in addition, we could quote a standard textbook on Software Engineering (e.g. by Ian Sommerville or Pressman). Another source might be the IEEE "Body of Knowledge". I would later give the full IEEE definition as an authoritative definition of what Software engineering is and leave the paragraph about the origin.

I would add a heading before the competing definitions so that they are not part of the intro.

I would leave out the definition involving advocacy as I think it is based on a misinterpretation of the cited reference. This states

We believe that software engineering can only advance as an engineering discipline by moving away from its current dependence upon advocacy and analysis, and by employing more systematic empirically-based approaches to developing an understanding of what works, why, and under what conditions?

I think "advocacy" is here used as a diplomatic way of saying "telling other people what to do, based on one's unsubstantiated opinion" – as made obvious by contrasting "advocacy" with "more systematic empirically-based approaches to developing an understanding of what works, why, and under what conditions", i.e. ascertaining empirically what engineering processes work before persuading people to use them.

I would expand or alter the other definitions to more fully reflect what is contained in the cited references, but indicate that they reflect secondary or erroneous usage.

I would then move the sections discussing the nature and meaning of software engineering to immediately follow (or even be part of,) the definition section (but only if they can be much condensed). While we are at it, we could remove some of the unreferenced stuff.

Scope and focus could perhaps be largely replaced by the ToC of the IEEE Guide to the Software Engineering Body of Knowledge [1].

I see someone created a page Software Engineering/Rework. I was going to propose delting it, since it doesn't seem to be in use, but perhaps we could use it for the purpose of "refactoring"" the whole article. It seems to be getting rather repetitive and rambling. --Boson 20:35, 6 February 2007 (UTC)

The first sentence is a compromise that has been hashed out over many years. It contains ideas that the general public can understand, such as "SEs make programs or applications," and it references the source ideas that SEs use (computer science, engineering, project management, etc).

There are many problems with IEEE definitions. They tend to emphasize government/military applictions and processes. They tend to dismiss non-commerial approaches, sucs as open source). They tend to overlook modern, agile approaches. Also, IEEE members are only a small fraction of the SE community, perhaps 3%. For those who will argue about data (the U.S. BLS says there are 750,000 SE in the U.S. alone, but the IEEE CS has only 60,000 members, at least half of whom are hardware types.)

Many people have offered over the years to say that "SE should be defined by the IEEE" or "SE should be defined by engineers". This appears to be yet another attempt by engineers to tell software people what they do. -- The Phantom Avenger for Software Engineering —The preceding unsigned comment was added by 69.49.173.16 (talk) 19:07, 14 February 2007 (UTC).

It is not about engineers telling software developers what to do, but we need to distinguish between "software engineering" as an engineering discipline and the development of software by any means, including engineering processes, craft practices, cowboy programming, etc. i.e. this is a dispute about linguistic issues, not substance. Perhaps we could just put a disambiguation note at the top of the article: This article describes software engineering in the IEEE sense of the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software. For the development of software in general, see Software development. —The preceding unsigned comment was added by Boson (talk • contribs) 18:38, 15 February 2007 (UTC).

Syntactic methods

I have added a "{{prod}}" template to the article Syntactic methods, suggesting that it be deleted according to the proposed deletion process. All contributions are appreciated, but I don't believe it satisfies Wikipedia's criteria for inclusion, and I've explained why in the deletion notice (see also "What Wikipedia is not" and Wikipedia's deletion policy). You may contest the proposed deletion by removing the {{dated prod}} notice, but please explain why you disagree with the proposed deletion in your edit summary or on its talk page. Also, please consider improving the article to address the issues raised. Even though removing the deletion notice will prevent deletion through the proposed deletion process, the article may still be deleted if it matches any of the speedy deletion criteria or it can be sent to Articles for Deletion, where it may be deleted if consensus to delete is reached. Jeepday (talk) 02:18, 17 May 2007 (UTC)

Question: What is the main similarity between a Software Engineer and a Programmer?

Answer: Neither one graduated from an engineering school

And thats why I added {{Main article: Controversies over the term Engineer}} into the "Debate over the term 'engineering'" section. That Article brings many of the different "Engineering Title" debates to 1 single well sourced article. Professional engineers, Security engineers, Cost engineers, software engineers, and Aircraft Maintenance Engineers are all represented, with much less trolling. Exit2DOS2000^•T•C• 10:57, 5 January 2008 (UTC)

Sorry, I can call myself a MSc in Software Engineering and I did graduated from an engineering school! Moreover, I am an ir. MSc, meaning I've completed the toughest kind of study around. And yes, I've seen loads of Algebra and Mathematical Analysis and Classical Physics and Quantum Physics and a bit of Relativity. And yes, I've seen how all parts of a computer work, from Electronics, transistors, integrated circuits, telecommunication, assembler, compilers, procedural programming/relational databases, object oriented programming, software architecture. I don't say that everyone that calls himself a software engineer is worth the name "engineer", but this doesn't mean there are no real engineers between them. If you are one yourself, you know who are the real ones and who are the fakes. For others it may be more difficult to tell the difference.