brian@dekalb.UUCP (Brian Charlton) (05/09/89)
I am a student and am new to this news group,so this may
seem like a stupid question to most of you. I read that soft-
ware engineering as a sub-discipline under computer science; but
I also read in an another news group that software engineers
were considered actual engineers (like AE,EE,ME ....).
What are the actual degree requirements of software engineers and also
what are their job definitions ?
-Brian
--
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| EMAIL : brian@dekalb or | " Yet another victim of |
| gatech!dekalb!brian | society " |
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*fad@think.COM (Franklin A Davis) (05/10/89)
In article <497@dekalb.UUCP> brian@dekalb.UUCP (Brian Charlton) writes: > I am a student... I read that soft- >ware engineering as a sub-discipline under computer science; but >I also read in an another news group that software engineers >were considered actual engineers (like AE,EE,ME ....). >What are the actual degree requirements of software engineers and also >what are their job definitions ? I'll quote a definition by Richard Fairley from "Software Engineering Concepts:" Software engineering is the technological and managerial discipline concerned with systematic production and maintenance of software products that are developed and modified on time and within cost estimates. Dr. Fairley was a professor of mine and chairman of the faculty at the late Wang Institute of Graduate Studies when I studied for my Masters of Software Engineering. He's now head of the MSE program at George Mason University. Having studied (and argued about) the details of SE for a year in school, and then working for nearly two, I feel I am just beginning to become a good engineer. In my five years of work before my graduate studies I think I was more a programmer than a true engineer. Almost everyone who programs computers for a living is now referred to as a "software engineer." I applaud the goal of having all programmers practice real engineering, but I'm afraid the use of "software engineer" as a job title is often inflated. Since there are only a few schools in the world so far that grant degrees in software engineering it would be impractical to have specific SE degree requirements for jobs. Fortunately the real world is often a good teacher, so people with CS degrees (or no degree at all) become proficient engineers with experience. My own working definition is that a software engineer is knowledgable and disciplined about all the tasks involved in creating a *finished product*, including specification, planning, design, writing test plans, coding, debugging, testing, documenting, and maintaining. The actual effort in writing code that just "works" is a small fraction of the total. Few CS departments devote more than a semester (if that!) to software engineering. I'm not sure the undergraduate level is a good time to concentrate on it -- the Wang Institute required at least 2 years' experience, and I think that was beneficial. But, as you'll probably hear over and over if you continue reading this group, anyone entering the field should be required to have some basic knowledge of the engineering aspects of software product development. Sadly, as I interview recent grads from excellent schools, I find this is rarely the case. --Franklin Some references: The Mythical Man-Month, F. Brooks, Addison-Wesley 1975. (READ THIS FIRST! It's fun.) Software Engineering Concepts, R. Fairley, McGraw Hill 1985. Software Engineering: A Practitioner's Approach, R. Pressman, McGraw Hill 1987. (He says, "A set of techniques, collectively called 'software engineering,' has evolved...[to] deal with software as an engineered product that requires planning, analysis, design, implementation, testing, and maintenance.") franklin a davis Thinking Machines Corp. Cambridge, MA 02142 617-876-1111 <fad@think.com> {ames, harvard, mit-eddie, uunet}!think!fad
kathyi@hpmcaa.mcm.hp.com (Kathy Iberle) (05/11/89)
Being new to this string, I'm a bit puzzled. In my (possibly outdated) experience, "programmer" usually refers to someone who has 2 years education (an associate's degree) and whose job is defined as implementing the detailed design done by a systems analyst. I believed this to be true in the DP world. In the engineering or technical programming world, it seemed that either you had junior engineers/ senior engineers (any of whom might or might not have an engineering degree in any engineering discipline), or you had jack-of-all-trades who do design, implementation, and testing. The jack-of-all-trades requires at least a BS (but not necessarily in CS) and often is called "software engineer" to distinguish him/her from the "programmer". Of course, this view was formed before most software engineering programs were in existence. I still have not met anyone who has actually graduated from one, though I have certainly learned much of the subject matter out of necessity. So, am I outdated? Would you refer to yourself as a "programmer" on a resume? Kathy Iberle
rsd@sei.cmu.edu (Richard S D'Ippolito) (05/16/89)
In article <40386@think.UUCP> Franklin A Davis brings up certain points that are central to the issue of software engineering. >I'll quote a definition by Richard Fairley from "Software Engineering >Concepts:" > > Software engineering is the technological and managerial > discipline concerned with systematic production and maintenance of > software products that are developed and modified on time and within > cost estimates. Dr. Fairley's excellent credentials aside, why is it that only software engineering includes "on time and within cost estimates" in its definition? Is it because those other engineering disciplines have long since incorporated the way to do this to the extent that it is no longer interesting to speak of it when it happens? I suspect that the above is _not_ the case, and that only more general statements of value were ever included in their definitions. I can think of several products of engineering, whose complexity rivals that of large software systems, which have been economically successful in the commercial markets, where cost overruns would lead to company failure. >...Fortunately the real world is often a good >teacher, so people with CS degrees (or no degree at all) become >proficient engineers with experience. I would take issue with that as a general statement, just as I would the statement that people with no medical degrees can become good physicians by real-world experience. Indeed, many can become good _pracititioners_ of the craft aspects of a trade, but few can assemble enough knowledge by mere practice. One of the difficulties is, that in addition to acquiring the scientific knowledge (which I agree comes from studying Computer Science), one must also acquire the engineering methods of systematically applying the knowledge. I find it difficult to believe that one can acquire enough knowledge of a technical field without the benefit of a formal period of study of the field, such as you suggest, though I suppose it has been done by those rare folks that you and I cannot hope to emulate. The engineering methods are even less likely to learned from inspection. One can more easily copy the products and even some of the methods of an engineer than one can learn the thinking behind them. As a result, those who learn solely by inspection suffer from an inflexibility, as they cannot adapt either the products or the methods to new situations. >...Few CS departments devote more than a semester (if that!) to software >engineering. I'm not sure the undergraduate level is a good time to >concentrate on it -- the Wang Institute required at least 2 years' >experience, and I think that was beneficial. All other engineering disciplines begin at the undergraduate level. I would even make the case that engineering training starts before that, mostly in ways that are not consciously seen as such. >But, as you'll probably >hear over and over if you continue reading this group, anyone entering >the field should be required to have some basic knowledge of the >engineering aspects of software product development. Sadly, as I >interview recent grads from excellent schools, I find this is rarely >the case. I'm not sure what the "engineering aspects of software product development" are. Do you mean engineering design or do you mean a more general knowledge of the _production_ aspects of software, which includes many management issues? Many of the production and management issues are peripheral to generating good design, though I agree that it is helpful for the engineer to know them. In fact, I would claim that the design engineering should drive the production and management, and not the other way around. Rich -- --------------------------------------------------------------------------- Ideas have consequences. RSD@sei.cmu.edu Richard Weaver ---------------------------------------------------------------------------
kathyi@hpmcaa.mcm.hp.com (Kathy Iberle) (05/16/89)
> The engineering methods are even less likely to learned from inspection. > One can more easily copy the products and even some of the methods of an > engineer than one can learn the thinking behind them. As a result, those > who learn solely by inspection suffer from an inflexibility, as they cannot > adapt either the products or the methods to new situations. This assumes that those CS types do not read nor take additional courses (often company-provided rather than at a bona-fide university). Once one has learned to think, one should be able to master any subject. Anyone who's interviewed with Hewlett-Packard should recognize that the aim of the interviews is to determine if the interviewee can think. In the real world, bona-fide software engineers with a degree to prove it are few and far between. The rest of us learn by reading, taking courses, hiring consultants, and by doing. It's not the ideal, but personally I'd rather try to turn a CS into a software engineer than a straight EE into a programmer. Kathy Iberle
UH2@PSUVM.BITNET (Lee Sailer) (05/16/89)
In article <497@dekalb.UUCP>, brian@dekalb.UUCP (Brian Charlton) says: >What are the actual degree requirements of software engineers and also >what are their job definitions ? > One thing to keep in mind when trying to answer this question is that the answer is likely to be very fuzzy, and vary a lot from school to school and company to company. But, in brief: Software engineering is about how to accomplish very large software projects on time and within budget. The skills required include computer programming, algorithm design, and the rest of the usual CS stuff, but also include project management, cost-accounting, organizational theory, and so on. Some schools have started a SE major. It might be in the School of Engineering, Arts and Sciences, Industrial Engineering, Management, Business, or who knows where. SE is an overlap of CS, Engineering, and Management. I guess it evolved as a separate entity for local historical and political reasons. That is, pure CS people think SE is too applied, Engineers don't think software is a thing that must be built, and Mangement doesn't have the technical skills.
UH2@PSUVM.BITNET (Lee Sailer) (05/17/89)
In article <1700002@hpmcaa.mcm.hp.com>, kathyi@hpmcaa.mcm.hp.com (Kathy Iberle) says: > >Being new to this string, I'm a bit puzzled. In my (possibly outdated) >experience, "programmer" usually refers to someone who has 2 years >education (an associate's degree) and whose job is defined as >implementing the detailed design done by a systems analyst. I believed >this to be true in the DP world. In the engineering or technical I think this is the most common usage in the Data Processing industry. However, in many graduate CS departments being a programmer (or hacker, or wizard, or superprogrammer) carries considerably more status. Actually, IBM coined the notion of Super Programmer some years back. The notion was that there are some jobs which might require a team of average software developers, but one really good developer could do it faster alone.
tomg@ann.MN.ORG (Thomas S. Greenwalt) (05/17/89)
In article <3359@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes: > >>...Fortunately the real world is often a good >>teacher, so people with CS degrees (or no degree at all) become >>proficient engineers with experience. > >I would take issue with that as a general statement, just as I would the >statement that people with no medical degrees can become good physicians by >real-world experience. Indeed, many can become good _pracititioners_ of the >craft aspects of a trade, but few can assemble enough knowledge by mere [Several paragraphs of good arguments] I agree that the 'real' world (whatever that is) is a good teacher. I am a case in point. I have no degree in anything and probably never will, however I am also more than a _good practitioner_ of the craft of programming. For many people organized rote learning may make them better programmers or software engineers, however many of the degreed people I have worked with, needed a couple years to learn that theory in the classroom doesn't always translate into a pratical and profitable piece of software. Of course just real world experience isn't enough by itself. I read everything I can get ahold of on OOPS, CASE, Software Engineering, design methodologies, etc, to keep learning on my own. The best thing I can say for a college education is that if I ever get a real job versus being a consultant, it would be easier to get a raise. -- Thomas S. Greenwalt {amdahl|hpda}!bungia!datapg!ann!tomg A.N.N. Systems +1 612-933-6467 tomg@ann.MN.ORG tomg@ann!uunet ----------------------------- Patience is a Vice -----------------------------
djones@megatest.UUCP (Dave Jones) (05/18/89)
From article <3359@ae.sei.cmu.edu>, by rsd@sei.cmu.edu (Richard S D'Ippolito): > In article <40386@think.UUCP> Franklin A Davis brings up certain points that ... > >>...Fortunately the real world is often a good >>teacher, so people with CS degrees (or no degree at all) become >>proficient engineers with experience. > ... > > I find it difficult to believe that one can acquire enough knowledge of a > technical field without the benefit of a formal period of study of the > field, such as you suggest, though I suppose it has been done by those rare > folks that you and I cannot hope to emulate. > Gimme a break. College is not magic and professors are not magicians. Of course it is possible to learn, and learn well, without going to college. I'm not recommending that anyone drop out, mind you. If for no other reason, that degree is a piece of paper that says you can start and finish a long, demanding project. When I was in college, rather recently in geologic time, there was no such thing as a C.S. degree. To get the piece of paper, I got a master's degree in mathematics. I also got a job as a computer operator and programmer, so I would have a machine to play with. And I read everything I could find about computers and programming. At the risk of sounding vain, if I'm ever on Jeopardy, it's, "Alex, I'll take computers for 1000," straight away, even though every hour I've spent in a college C.S. classroom has been on the chalkboard side of the front desk.
cline@sunshine.ece.clarkson.edu (Marshall Cline) (05/25/89)
In article <5004@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >From article <3359@ae.sei.cmu.edu>, by rsd@sei.cmu.edu (Richard S D'Ippolito): >> In article <40386@think.UUCP> Franklin A Davis brings up certain points that >>>...Fortunately the real world is often a good >>>teacher, so people with CS degrees (or no degree at all) become >>>proficient engineers with experience. >>I find it difficult to believe that one can acquire enough knowledge of a >>technical field without the benefit of a formal period of study of the >>field, such as you suggest, though I suppose it has been done by those rare >>folks that you and I cannot hope to emulate. >Gimme a break. College is not magic and professors are not magicians. AGREE! The idea that coursework is _necessary_ for learning is LUDICROUS! Coursework isn't even _sufficient_ for learning! However: Raw, Hard, Industry Experience seems to show that teaching Computer Scientists how to be an Engineer is harder than teaching an Engineer how to program. The point is not that Engineering _coursework_ is required, as much as the whole _mentality_ that is developed over time when trained (formally or informally) as an Engineer. >... I'm not recommending that anyone drop out, mind you.... AGREE! Neither am I. High Tech job opportunities invariably list Education Requirements. That's the way "The System" evaluates people. Unfortunately we've no way of rewarding _ability_; instead we use _education_. We've all known "well educated idiots," and we've all known people who are excellent at what they do but lack a "piece of paper" (diploma). Unfortunately The System rewards the former but not the latter. I'd like to change the way it works, but I can't -- I have no better way. How else would we evaluate people's abilities? Testing? That's no good, because some people choke under testing situations, yet they might be very skillful and proficient in the day-to-day grind. Marshall -- ________________________________________________________________ Dr. Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591
cline@sunshine.ece.clarkson.edu (Marshall Cline) (05/25/89)
I just wrote an article with the same "Subject" but forgot to mention a reference to the statement that it's easier to teach Computer Science to Engineers than to teach Software Engineering to Computer Scientists. This idea was elucidated in the most recent CACM in an article about the Software Engineering Institute (at CMU?). Marshall -- ________________________________________________________________ Dr. Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (05/25/89)
From article <CLINE.89May24173656@sunshine.ece.clarkson.edu>, by cline@sunshine.ece.clarkson.edu (Marshall Cline): > I just wrote an article with the same "Subject" but forgot to mention > a reference to the statement that it's easier to teach Computer Science > to Engineers than to teach Software Engineering to Computer Scientists. > This idea was elucidated in the most recent CACM in an article about > the Software Engineering Institute (at CMU?). Actually, that article states (CACM, May '89, page 596): "[...] many software development practitioners believe it is easier to teach programming to an engineer than it is to teach engineering to a programmer. The SEI Education Program has been repeatedly asked for recommended undergraduate software engineering degree requirements. We resist by arguing that the best education remains a solid major in computer science followed by graduate professional education such as an MSE (Master's in Software Engineering) program." Here at Clemson (an affiliate of the SEI), we require software engineering coursework of all computer science undergraduates; that requirement will soon expand to include two courses. In the same article (page 602): "In terms of numbers of students affected, the SEI Education Program can make its greatest impact by influencing undergraduate computer science curricula." Not all universities require software engineering of BSCS candidates, but the winds of change are blowing. Until then, industry can accelerate the trend by concentrating their undergraduate recruiting efforts on the universities which deliver "a solid major in computer science" which includes significant software engineering coursework, and by doing their graduate recruiting at universities whose computer science programs allow for software engineering specialization, until graduates begin to emerge from newly established MSE programs. Bill Wolfe, wtwolfe@hubcap.clemson.edu
rgo@berlioz (Ronald Olshausen) (05/26/89)
In article <5596@hubcap.clemson.edu> billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu writes: >From article <CLINE.89May24173656@sunshine.ece.clarkson.edu>, by cline@sunshine.ece.clarkson.edu (Marshall Cline): CACM Article excerpt: > > "[...] many software development practitioners believe it is > easier to teach programming to an engineer than it is to teach > engineering to a programmer. The SEI Education Program has > been repeatedly asked for recommended undergraduate software > engineering degree requirements. We resist by arguing that > the best education remains a solid major in computer science > followed by graduate professional education such as an MSE > (Master's in Software Engineering) program." > I'd have to agree with the CACM article. Over the course of undergraduate and graduate study of Computer Science, one can master the basics of "programming in the small", as well as develop certain problem-solving skills. I have my doubts, though, as to whether academia can cultivate a commitment to the software life cycle, as can industrial experience. I was TA for a Senior-level software engineering course while I was in grad school. We tried to have the students tackle large software systems, over the course of a full academic year, starting with the requirements analysis and ending up with a deliverable product. We only encountered limited success with this approach. Whatever one chooses for a working definition of software engineering, we can probably agree that it is a discipline in its infancy. As a research discipline, software engineering is to me rather nebulous. There are some researchers who are convinced that the high cost of software systems development can best be alleviated by throwing even more software at the problem. Others attempt to formalize, by various methods, the specification, design, and test procedure for aggregate software systems. There seems to be a great deal of fragmentation, even within the research community, as to what exactly software engineering comprises. My own professional software engineering experience comes in the area of real-time, embedded systems. For that, I am convinced that the key to on-time, under-budget delivery is a thorough requirements analysis. For this, the bottom line is that this phase of the project needs to be staffed with individuals possessing both strong analytical skills and communication skills, and a commitment to the "big picture" of the software life cycle. "Computer Scientists", as opposed to "systems engineers", may not necessarily be very well suited to this task. Ron Olshausen NSC-Santa Clara rgo@logic.nsc.com
billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (05/26/89)
From article <263@blenheim.nsc.com>, by rgo@berlioz (Ronald Olshausen): >> the best education remains a solid major in computer science >> followed by graduate professional education such as an MSE >> (Master's in Software Engineering) program." > > I'd have to agree with the CACM article. Over the course of > undergraduate and graduate study of Computer Science, one can > master the basics of "programming in the small", as well as > develop certain problem-solving skills. I have my doubts, though, > as to whether academia can cultivate a commitment to the software > life cycle, as can industrial experience. Which is why "cooperative education", whereby students do real work for real companies in their area of major emphasis over the summer, is becoming increasingly popular; it provides a sense of practical value which reinforces the value and motivates the understanding of the software engineering education they're getting in the classroom. % the bottom line is that [...] the project needs to be staffed with % individuals possessing both strong analytical skills and communication % skills, and a commitment to the "big picture" of the software life cycle. % "Computer Scientists", as opposed to "systems engineers", % may not necessarily be very well suited to this task. Perhaps that should read: "Computer scientists without any software engineering education and without any practical experience may not necessarily be very well suited to this task"; the validity of this observation is precisely what is motivating the increasing emphasis on software engineering and cooperative education. Bill Wolfe, wtwolfe@hubcap.clemson.edu
chrisp@regenmeister.uucp (Chris Prael) (05/26/89)
From article <5596@hubcap.clemson.edu>, by billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,): > From article <CLINE.89May24173656@sunshine.ece.clarkson.edu>, by cline@sunshine.ece.clarkson.edu (Marshall Cline): >In article <5004@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >>From article <3359@ae.sei.cmu.edu>, by rsd@sei.cmu.edu (Richard S D'Ippolito): >>> In article <40386@think.UUCP> Franklin A Davis brings up certain points that Gentlemen, I am going to throw stones all over the placew here. I hope I don't offend too many of you. >>>>...Fortunately the real world is often a good >>>>teacher, so people with CS degrees (or no degree at all) become >>>>proficient engineers with experience. In my observation, most people with CS degrees have come out of school thinking like a technician. While they may eventually may become very experienced technicians, they rarely make the transition to engineer. >>>I find it difficult to believe that one can acquire enough knowledge of a >>>technical field without the benefit of a formal period of study of the This assertion presupposes that there IS a formal course of study in the engineering of software. It appears to me that there is not. Most of the people who really become software engineers, do so through the apprenticeship route (informal). >>Gimme a break. College is not magic and professors are not magicians. Nor are most of the people in industry. >AGREE! The idea that coursework is _necessary_ for learning is LUDICROUS! >Coursework isn't even _sufficient_ for learning! Bravo! Well said! >However: Raw, Hard, Industry Experience seems to show that teaching Computer >Scientists how to be an Engineer is harder than teaching an Engineer how to >program. The point is not that Engineering _coursework_ is required, as much >as the whole _mentality_ that is developed over time when trained (formally >or informally) as an Engineer. Again, well said. My experience has been that it is easier to train a person with a degree is math or english with a couple of course hours in programming to be an engineer than it is to train a person with a CS degree. The latter has generally required untraining first. There have been exceptions: a young woman with a MSCS who was a real artist in C. >High Tech job opportunities invariably list Education Requirements. Most managers (even with "programming" experience) are so short in knowlege that they are forced to rely on credentials. > Actually, that article states (CACM, May '89, page 596): > > "[...] many software development practitioners believe it is > easier to teach programming to an engineer than it is to teach > engineering to a programmer. That is because engineering is a disciplined sequence of behaviors that result in a product. The product may be inspired or pedestrian, but it generally performs the intended function safely and effectively. Note that all forms of engineering deal in two processes: the process of building and the process of function. For example, the purpose of a gasoline engine is the process of converting energy stored in the gas to rotational energy at the fly wheel. Programming is simply building abstract artifacts from an abstract class of nuts and bolts using abstract wrenches and screwdrivers. > The SEI Education Program has > been repeatedly asked for recommended undergraduate software > engineering degree requirements. We resist by arguing that > the best education remains a solid major in computer science I question the solidity of a major in CS. > followed by graduate professional education such as an MSE > (Master's in Software Engineering) program." I also question the assertion that a graduate education is professional in nature. These kids are mechanics when they get to us, not engineers. > Not all universities require software engineering of BSCS candidates, > but the winds of change are blowing. Until then, industry can > accelerate the trend by concentrating their undergraduate recruiting > efforts on the universities which deliver "a solid major in computer > science" which includes significant software engineering coursework, Industry is also filled with mechanics. They don't genreally know what to insist on! The final point. How did I get to be such a know-it-all? I was trained by a master twenty odd years ago. Who trained him, I really don't know. If you want to learn how to train software engineers, go get Warner King out of IBM and have him teach you how he does it. Chris Prael
rsd@sei.cmu.edu (Richard S D'Ippolito) (06/03/89)
In article <CLINE.89May24173256@sunshine.ece.clarkson.edu> Marshall Cline writes: >In article <5004@goofy.megatest.UUCP> Dave Jones writes: >>From article <3359@ae.sei.cmu.edu>, by Richard S D'Ippolito: >>> In article <40386@think.UUCP> Franklin A Davis brings up certain points >>>that >>>>...Fortunately the real world is often a good >>>>teacher, so people with CS degrees (or no degree at all) become >>>>proficient engineers with experience. > >>>I find it difficult to believe that one can acquire enough knowledge of a >>>technical field without the benefit of a formal period of study of the >>>field, such as you suggest, though I suppose it has been done by those rare >>>folks that you and I cannot hope to emulate. > >>Gimme a break. College is not magic and professors are not magicians. > >AGREE! The idea that coursework is _necessary_ for learning is LUDICROUS! >Coursework isn't even _sufficient_ for learning! This is getting a bit far afield from the original context, isn't it? Why is only college instruction considered formal training? What about previous schooling and apprenticeships? I will stand by my original statement, even in the isolation that it's presented above. >However: Raw, Hard, Industry Experience seems to show that teaching Computer >Scientists how to be an Engineer is harder than teaching an Engineer how to >program. The point is not that Engineering _coursework_ is required, as much >as the whole _mentality_ that is developed over time when trained (formally >or informally) as an Engineer. I suspect that you are not using formal in the sense that I was, that is, within a carefully defined educational framework, as opposed to simply purchased schooling. >High Tech job opportunities invariably list Education Requirements. >That's the way "The System" evaluates people. >Unfortunately we've no way of rewarding _ability_; instead we use _education_. Nonsense! The education completed is simply used to determine initial compensation; companies which fail to base continuing compensation on performance pay the penalties in many ways. Universities and similar organizations can get away with this almost indefinitely because their reputations are slow to change and the customers (read students) have no direct, immediate economic power over the suppliers (read individual professors). Additionally, they have no immediate way of determining the value received, unlike employers, who can obtain current feedback of job performance. >I'd like to change the way it works, but I can't -- I have no better way. >How else would we evaluate people's abilities? You are again confusing potential with performance. We could go back to the old educational system where the students paid for each class at the end of it and refused to come back to the next one if unsatisfied! Restaurants and other service providers survive this every day. Immediate and direct economic feedback does the trick every time! Rich -- --------------------------------------------------------------------------- Ideas have consequences. RSD@sei.cmu.edu Richard Weaver ---------------------------------------------------------------------------
merriman@ccavax.camb.com (George Merriman -- CCA/NY) (06/11/89)
An interesting article on this general subject appears in _Open Channel_ department of the May, 1989 issue of the IEEE _Computer_ magazine. It is by Robert L. Baber, who describes himself as a practicing "software developer of long standing" and as an "engineer (electrical) by education." He argues that the term "Software Engineering", as it is commonly used today, describes what is really a management activity rather than an engineering activity and suggests that we start using another term so as to not confuse it with what software engineering ought really to be. He suggests the term "Integrated Software Life Cycle Management (ISLCM)" as suitably impressive to satisfy our desire for pomposity. He describes what he terms engineering as: "The application of scientific knowledge and principles to the task of designing and constructing a device, machine, or system of economic value . . . Especially noteworthy is that the engineer employs a scientific, theoretical foundation to verify -- by systematic calculation and before the object is actually built -- that a proposed design will satisfy the specifications." Though I am not an engineer, I've had occasion to work in several "engineering departments", so to speak, and find this article fits with my experience. I think it is important to keep in mind that someone employed as an engineer is often called upon to be a manager and designer as well as an engineer and the "get the project out on schedule and under budget" aspect of the job is clearly part of the management side of the job. For example, in construction work project management is often handled by non-engineers (the contractor's staff) and while an engineer is called upon to verify that a design (by an architect) will not fall down and meets code, he may never even visit the site or see a schedule. So if "Software Engineering" isn't really software engineering, what is? I have yet to see a software shop where anything comparable to the "systematic calculation" mentioned in the article goes on (if you don't believe me, go watch a consulting structural engineer at work), and I think it will be a while before a true software engineering discipline is practiced on a wide scale in this industry, at least my part of it. When it happens I think it will be based on the sort of rigorous proof-of-correctness and algorithm performance analysis taught and developed in the more mathematically inclined CS departments. The trouble is, I think the theory needs to be distilled down to something we ordinary mortals can handle before it will be usefull. We need our own Oliver Heavyside.