From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_40,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bf72ca9e8a6b3cf X-Google-Attributes: gid103376,public From: tmoran@bix.com Subject: Re: Software Engineering in Florida Date: 1999/11/08 Message-ID: #1/1 X-Deja-AN: 546026657 References: <3826F9A8.452F305@pwfl.com> X-Complaints-To: abuse@pacbell.net X-Trace: typhoon-sf.snfc21.pbi.net 942089822 207.214.211.15 (Mon, 08 Nov 1999 11:37:02 PST) Organization: SBC Internet Services NNTP-Posting-Date: Mon, 08 Nov 1999 11:37:02 PST Newsgroups: comp.lang.ada Date: 1999-11-08T00:00:00+00:00 List-Id: >I can think of no field of engineering normally recognized as such which does >not in some way deal with the arrangement of physical matter into some kind of I think this is a red herring. Society/the Law has no particular interest in regulating based on whether physical matter is rearranged. The important thing is the professional's impact on the citizenry. Once upon a time there were a lot of "engineers" designing steam boilers, which blew up entirely too often. Criminal or civil penalties on the designer were of scant comfort if many people were killed and great damage was done. So legislatures started requiring certain qualifications of such "engineers" to lessen the problem. As software insinuates itself into more and more areas, and the damage done by bad software starts to appear in large type on front pages, it's reasonable to expect legislatures will use the same technique as a tool to lessen the problem. Then there's also the "raise wages by limiting the supply" aspect of such regulations, which potentially applies as much to "software engineers" as to "professional engineers", doctors, or beauticians. >Another - and in my mind, very fundamental - difference between what we >software practitioners do and what "engineers" do is that we never build the >same thing twice. A civil engineer can say "Well, this structure is a >... >Its not like we have in the field "Sort" experts as the CE's might >have a "Cantilever Bridge" expert ... Look at Knuth on sorting. He does not in fact give a single "sort algorithm", but shows many, which are optimum in different circumstances. An occasional sort of a few thousand short records on a fast machine may be appropriately handled by whatever sort is most conveniently available in the library, just as you can bridge a small ditch with any old plank. But someone designing an external sort of a massive, nearly sorted, database, shouldn't rely on that library sort, but should in fact call on a "Sort" expert, just as the CE's would have a "Cantilever Bridge" expert. >The "engineer" applies a set of historically discovered rules in solving a new, >yet categorizable, problem. The "software practitioner" is in the business of >dreaming up the rules to solve a problem. It seems to me there is something >very different about the two professions. "Originality is the root of all evil" is perhaps an overstatement, but a good software practitioner will certainly try to re-use existing, debugged, code, or at least existing algorithms and data structures, rather than inventing new ones on the spot. Ditto for existing interfaces and APIs as opposed to slightly "improved" ones. At a higher level of abstraction, the engineer who wants to create a transportation system, say, tries to dream up combinations of historically discovered techniques - bridges of various kinds, roadways, etc, that will best do the job. The software practitioner faced with "design a computer system to let us sell books over the internet" will dream up combinations of large or small servers, web page software, databases, etc. that will best do the job. Just as the software practitioner might decide that something unusual - a small, cheap, specialized wireless ordering computer people can keep on their bookshelves, say, might be part of the best solution, the engineer might decide that people-carrying pneumatic tubes would be part of his best solution. When looking at an engineer's work, or a software practitioner's work, it's a heck of a lot more common in either case to say "yes, that's a good idea to use such and such for that part", than to say "good grief - I would never in a million years have thought of that way of doing things!".