Encyclopedia > Talk:Software engineering
Talk:Software engineering
Oh great, another kook to deal with. The article you removed is pretty sloppy, but what you replaced it with was nothing but a personal screed that the whole field is nonsense. Well it may well be, but it is a respected field of study that deserves to be covered in an encyclopedia along the lines of those who study it and write about it. The fact that you are not alone in claiming that the field of study has been largely unsuccessful is something that ought to be covered, but that in no way invalidates the field of study itself, its definitions, its goals, or its methods. It merely reflects that the field itself is still in its infancy.
There are lots of programmers here, as you might suspect with any net-based group. I've been programming since 1979, and professionally since 1982, so I think over 20 years in the business qualifies me to say that your opinions here are not mainstream. Software engineering methods outside of mere computer programming are discussed and used in every serious software enterprise, and are taken seriously by most. -- Lee Daniel Crocker
- So this might perhaps qualify you to come up with a list of these methods along with some explanations. The article as a whole needs more attention. --Hirzel 09:21 15 Jun 2003 (UTC)
"respected" by whom?
I used to believe in this field. But note the incredible bias of its typical practitioners: total failure "in no way invalidates the field of study itself, its definitions, its goals, or its methods. It merely reflects that the field itself is still in its infancy." This is like the dudes still looking for the particle in the accelerator that will a GUT suddenly appear.
They never acknowledge the probability that their whole field is built on a set of wrong premises. In this case, that "software engineering" is just "requirements engineering" with less accountability, more jargon, and absolute disconnection between the bodies of real people affected by actions of real users. Thankfully, this point of view is in decline. Most of us today would accept that a perfectly "engineered" video game showing how to turn ordinary household implements into weapons of mass destruction would be well within their paradigm, and the definitions, goals and methods that they use, but also would accept that it would be unlikely to be allowed to reach beyond such an "infancy" for various legitimate ethical and social reasons.
Any attempt to actually "engineer" software soon discovers that without the body references implied by the real fields of engineering (e.g. chemical, mechanical, electrical) there is no way to assess safety or closure problems. Accordingly, the "field of study itself, its definitions, its goals, or its methods" is invalid ethically, invalid ontologically, and invalid bodily.
So, my position is that software engineering does not exist, cannot exist, is a marketing term for a marketing concept, and to those who believed in it, is a stupid attempt to impose simple models on complex processes. It is just as absurd to talk about "requirements engineering" in any other field of design. This entire characterization of the process of creating complex tools or instruments has been discredited thoroughly, along with the SEI CMM that helped spawn it. There is no value whatsoever in the term or concept of "software engineering" excpet insofar as software is part of other, more operationally bound, forms of engineering. One might as well call the field "persuading the paying client that certain of his requirements do not exist", i.e. marketing.
The reader is far far better off learning how to distinguish an ontological distinction from an operational distinction[?] from an "ordinary" distinction, which will drastically aid their listening and understanding. Also to have a general notion of risk and of philosophy of action so that they do not make the mistake of assuming that actions carry uniform risk to the user or their surroundings. If we intend to introduce the rudiments of software design here, as we have started to do in object-oriented programming, then we should employ those terms as much as we can, e.g. problem domain analysis[?], legacy domain analysis[?], solution domain analysis[?]. We should certainly be sure to outline schema and ontology as applied to the process of laying out a software design itself.
But under no circumstances should we pretend that software "risk" or "benefit" can be assessed outside of a foundation ontology or political economy.
The idea that software could be engineered to better and better meet user "requirements" until it became inseparable from their daily lives has been thoroughly discredited. First by the sloughing-off by coders and users of all products of more disciplined processes, then by the failure of OOP to produce any "reusable components" outside the political standards process, then by the "dotcom boom" and the pending collapse of Microsoft once honest stock option accounting is in place.
Personally, I think that the day that this Windows Religion collapses, to be replaced by many fragmented subsystems, and the day that the Web Religion collapses, it will be relatively clear that the so-called "engineering" was simply bending human belief systems to fit what the systems could do at the time. That no "engineering" in the sense of taking state of the art science and turning it into practical or useful tools was occurring. That the entire process is much more viral and organic and more like gardening.
And, likely, that the control subsystems and highly constrained simulations, e.g. of hardware that track its states in a device driver, will not be seen as any kind of "engineering", but rather, as Dykstra put it, "computer science" proper - creating mathematical models to closely model the real world.
It might also be seen, like economics, as a sub-branch of general systems theory or philosophy of action. But I wouldn't hold my breath. More liely the terms "software engineering" and "requirements engineering" will die a well-deserved death together.
Here's the paragraph about the Australian failures. Some of these might be good examples, but they're certainly not as well known and central to the field as the ones mentioned, and I don't know whether they led to advancements in the field or if they are good examples of failure of specific methodologies that would merit including them. More info is needed about them; a merelist of screweps doesn't make a good article. --LDC
Other big stuffups I know about, though they were from the 1980s and 1990s and they're all Australian:
- The automatic tollway in Melbourne was delayed a year due to engineering difficulties, but even with the delay the software wasn't ready and they couldn't charge tolls for the first three months of operation.
- The automatic ticketing system for Melbourne's public transport was delayed for years because of software difficulties. (It is still hated, but that has more to do with hardware and politics rather than strictly software).
- The combat system for Australia's Collins-Class submarines was so bad, it has had to be scrapped and replaced with an American system.
- The Jindalee Over-The-Horizon radar project was delayed for years because Telstra, who were contracted to do the programming work, couldn't get it right. They were eventually sacked and Rockwell was given the contract.
"In very recent developments (as of April 2002) apparently Texas is considering issuing the PE license for software engineers while California is considering outlawing the use of the term Software Engineer as a noun or field of employment."
- my money's on California - Texas wants this for military industrial complex reasons, as there has traditionally been little consumer or industrial software produced there that isn't ultimately destined for military use - the different character of the two regions' software industries might well be the cause for the difference. Another view is that "Software engineer" is a military term, since only the military actually has a policy of uniform risk for all elements of a system, and can put a dollar price on a human users' life and admit it. 24
I think the article needs some cleanup. There are a variety of views out there in the world on what constitutes software engineering, and the article captures some of them (but not all) and those it does are somewhat scattered.
My own bias, born out of working over 20 years in software development (and most of the time holding the title "software engineer" at whatever company I was working for at the time), is that there are a boatload of coders and programmers out there in the world and damn few software engineers. Even though I was given the SE title, the vast majority of what I did was not SE but rather designing, coding, and debugging. And while I have had a fascination and familiarity with SE principles, very few of the organizations and managers that I worked for were willing to put known good SE principles into practice in their organizations. Maybe it has just been my bad luck (embedded software for telecom systems, mostly, and for some consumer products).
- My couterexample. My father is a professional chemical engineer who for years spent his days calculating flow rates in pipes, driving out to the site to make sure the construction crew was busy, and editing the monthly status reports. None of this takes a professional engineer to do well. An intern could do the calculations and a secretary could do the rest. That did not make him any less of an engineer, nor make him any less appropriate for the job. As far as I can tell, most people are overqualified for what they do 90% or more of the time.
- Similarly with programming. Most software engineers spend their days programming. That does not make them any less software engineers, nor any less appropriate to the job. The reason you want software engineers writing code is so that in those 10% of the cases where there is more to consider, they can.
I draw the distinction that software engineering, as opposed to mere programming (designing, coding, debugging), is about how to construct software in ways that are efficient and predictable in terms of resources required, provide predictable quality, and in ways that scale up to large projects and/or teams of people. It's about getting feedback from development process to improve the process. In many ways it is more like a management discipline, and is only remotely related to computer science.
I tend to agree with Steve McConnell (see his book After the Goldrush) that SE will sooner or later be regulated, so the industry better get prepared. I think that other more established fields of engineering (civil, mechanical, chemical, electrical, etc) can provide some good general examples and inspirations, but requiring an SE to learn details of stress analysis or electrical circuits is pretty useless unless the SE works in software related specifically to those fields. Grizzly[?]
- The first attempts to regulate civil engineering in the U.S. began in the early 1800s and again after the civil war. However it was in the early 1900s that regulation caught on. Software may be like this, where people fight about it for 50 or 100 years, before they actually do it. People have been doing civil since before the Roman empire. We have been writing software for 50 years. It might take a while to figure out what and how to regulate.
- Besides, if all software engineers work in India or Russia by next year (which seems too likely), who will be left to care?
The most convincing arguments against the idea of software "engineering" are poorly presented here. Certainly Gerald Weinberg[?] didn't believe in it much. But, beyond that, whole aspects of the argument are not presented:
- Lawrence Lessig's convincing argument that coding is more like law, in that it expresses a certain social ethic by deciding what to ignore/consider in making detailed decisions.
- Bill Joy's argument that "better software" can only enable its priveleged end users, make reality more powerpointy as opposed to more humane, and ultimately run away with itself so that "the future doesn't need us". He openly questioned the goals of software engineering in this respect, asked why isn't it trying to be more ethical rather than more efficient.
- Donald Knuth's alternate concept of literate programming, which is about as anti-engineering as you can imagine.
- An alternative is not necessarily a criticism. Red is not a criticism of blue. Rocks are not a criticism of water. So, literate programming is not necessarily a criticism of software engineering. The purposes are different. Knuth writes and sells text books, so his concepts makes sense for him. But praticing software engineers write and sell applications, so another approach makes sense for them. Perhaps, there needs to be a list of alternative approaches to software engineering.
- A large part of the current software engineering initiative is asking what proper ethics for software engineers should be. They may not have come to the same conclusion that Joy came, but they are working on the same issue. Perhaps there needs to be a big discussion of SE ethics.
- I don't know much about Lessig's argument, but sounds interesting.
- Please add your notes to the article.
I'm not sure what you mean when you say that Gerald Weinberg doesn't believe in software engineering. Perhaps "software engineering" is not his preferred term, but he has a slew of books out, including the "Quality Software Management" series, which are about software engineering -- applying systems thinking as well as psychology and other applicable technologies to the software development process.
Could somebody provide a link or some details about the Ariane disaster please? I think it had something to do with integer to floating point conversion or range overflow. --Hirzel 11:05 Feb 19, 2003 (UTC)
Not to insult Knuth, but the recent addition of Knuth/TeX seems wierd. Much better examples of practitioners and applications should be easy to find. How about CTOs of successful software companies, etc? What are the most commonly used shareware applications? Knuth is the hardest core computer scientist in existance.
The intro passage should be reworked. It it way to general. Actually anything which is not computer hardware is "software engineering". It is even claimed that it is a community. Could anybody put this in better shape please? If not I might do it in the future (some time, maybe) --Hirzel 09:11 15 Jun 2003 (UTC)
- There is a web site http://www.software-engineer.org/ that treats software engineering as a community. Many new books about software engineering refer to it as a community. For example: Code Reading by Spinellis pg xxiii.
What is the source of the following figures?
| Number of Practitioners in U.S. in 2000 | 640,000 | 25,000 |
| Number of Practitioners in World in 2000 | unknown | unknown |
- The source was the U.S. 2000 census, which is pretty good, because they sent out forms to everyone residing in the U.S. and asked them what profession they practice. The CS profession is defined mostly as CS research. There are also about 27,000 (i forget exactly) CS educators. There are 640,000 people who full time worked in software engineering. Try www.bls.gov [.us].
There is a big difference between what the IEEE says that software engineering is and what software engineers say that software engineering is. Remember that there are 640,000 software engineers and maybe 50,000 people in the whole IEEE who do software engineering. The IEEE is maybe 7% of the profession.
They like to think they can tell everyone else what their job is, but they have engaged in activities to harm all other software engineers (exporting their jobs to India and stuff) in IEEE publications proving that they disrespect what everyone else in software engineering does. In the U.S. and Europe, one should never start with the IEEE, unless you are trying to make yourself unemployed (or get a government job).
Is it Software engineering vs. programming? Or is Software engineering just better programming?)
This is an excellent question. In the U.S. there are 640,000 professional software engineers and about 550,000 professional programmers. The difference is murky. I hope we can agree that they are related, but distinct professions.
I personally believe that software engineering is about a bigger scope, but both are about code.
- Thank you for the answer. So there are 1'190'000 persons occupied producing software? Roughly one out of 200 in the U.S. Or are there software engineers who are at the same time programmers? I agree basically with your conclusion. Hirzel
- Yes, there were about 1.1 or 1.2 million software developers in the U.S. in 2000. It is probably a little bit less (I guess about 1.0 million) in 2003, because of the tech recession.
Sharpened criticism somewhat
That section listed the criticisms that were in previous drafts of this article, or criticisms I have heard recently. However, I wonder whether they should be sharp or dull. I put a long-dash and a response to blunt each criticism. I did so, because there are many people who want to harm the software engineering profession. But, I believe that this article should make software engineers look good. In any case, the section needs improving.
- I agree that it needs improving. However I do think that the aim of the article should just be to describe sw engingeering, not to make it look particularily good. For example there is a paragragraph -
- Software engineering arose out of the so called software crisis of the 1960s, 1970s, and 1980s, when many software projects had bad endings. Many software projects ran way over budget and schedule. Some projects caused property damage. A few projects caused loss of life. As software becomes more pervasive, we increasingly recognize the need for better software. The software crisis was originally defined in terms of productivity, but evolved to emphasize quality.
- That is another excellent question, how to balance the points of view. There are many, many web sites that trash practitioners, usually to justify their own approach. For example the SEI web site has a letter from Cross http://www.sei.cmu.edu/director/aboutSEI (June 20, 2003) saying:
- Commercial software products today are riddled with defects--commonly known as "bugs"--that are introduced during the software's design and development. As we come to rely increasingly on systems that are interconnected in networks, the stakes are rising. Defects in products that are accessible to the Internet render them vulnerable to cyber attacks. The SEI's CERTŪ Coordination Center (CERT/CC) documented more than 4,000 commercial-product vulnerabilities this year and determined that more than 95% of the 82,000 unique cyber incidents it investigated were a direct result of intruders exploiting such vulnerabilities. Yet the massive number of vulnerabilities seen in commercial software can be attributed to a modest number of root causes. These defects, and hence most cyber attacks, could be prevented if vendors used the proven best design techniques of software engineering.
- Cross then explains why the SEI is the font of all wisdom and why they know more than everyone else in the world. I hope the wikipedia web page will be more generous and kinder to software engineers.
- The nineties are not mentioned: Does this mean that the sw crisis is over? Or are people just ashamed of still speaking of a sw crisis? --Hirzel 11:11 20 Jun 2003 (UTC)
- There have always been problems and there will always be problems. However the 1970s and 1980s were the heydays of using the term "software crisis".
Perhaps the following link might be useful for writing something about the topic in the article http://www.dreamsongs.com/Feyerabend/Feyerabend
--Hirzel 20:27 4 Jul 2003 (UTC)
All Wikipedia text is available under the terms of the GNU Free Documentation License
|
Search Encyclopedia
|
Featured Article
|