amanda@visix.com (Amanda Walker) (04/16/91)
In article <jls.671514765@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: I'm a bit confused. Is it your belief that software engineers do NOT work on problems directly related to the real world? Precisely. Hardware engineers, or electrical engineers, and so on work on problems directly related to the real world. So-called "software engineers" work on problems with symbolic systems that may happen to model aspects of the real world, or may not. In fact, some of the most popular applications of computer technology (and some of the most in need of the techniques often called "software engineering") are problems that are quite explicitly *not* part of the real world: simulation and modelling, statistical and numerical analysis, user interfaces, Usenet... These are all purely symbolic. They involve manipulating symbols and information. I like engineering. Put simply, I like building stuff. Creating a piece of software, though, is a lot more like writing something than building something. You just have a real literal-minded audience :)... I thought that satellites, dishwashers, dialysis machines, airplanes, telecommunications equipment, laptop computers, relational databases, finite element analysis models, and, well, actually, every OTHER thing I've seen software used for was part of the real world. What? You mean I can wash my dishes with software? Wow. What a concept. A relational database is part of the real world? I thought it was a symbolic framework for organizing information (which is about as abstract as it can get). I've seen *hardware* used in the real world, but not software. All I've ever seen software is manipulate symbols. Even low-level stuff like device drivers and barcode scanning software... I think I'd ask them to solve some problems. Probably have them rig up an interface to some device, write some queries for a database, reverse engineer a design from some legacy code, etc etc etc. You know--do some software engineering. In most engineering disciplines, tests are done by testing knowledge, not by testing performance. What you describe sounds more like an exam in art, music, or writing (usually called a "practical" or "recital" exam). Hmm... I wonder how that could be? Think of it as the kind of thing lawyers have to do to pass the bar, or doctors have to do to become doctors. Are lawyers and doctors engineers? Wow, learn something new every day :). -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- Entropy requires no maintenance.
dan@ece.arizona.edu (Dan Filiberti) (04/16/91)
In article <1991Apr15.205218.6914@visix.com>, amanda@visix.com (Amanda Walker) writes: |> In article <jls.671514765@rutabaga> jls@rutabaga.Rational.COM (Jim |> Showalter) writes: |> |> I'm a bit confused. Is it your belief that software engineers do NOT |> work on problems directly related to the real world? |> |> Precisely. Hardware engineers, or electrical engineers, and so on work |> on problems directly related to the real world. So-called "software |> engineers" work on problems with symbolic systems that may happen to model |> aspects of the real world, or may not. In fact, some of the most popular |> applications of computer technology (and some of the most in need of the |> techniques often called "software engineering") are problems that are quite |> explicitly *not* part of the real world: simulation and modelling, |> statistical and numerical analysis, user interfaces, Usenet... Uh, I don't think you live in the real world...people in the real world use user interfaces...people in the real world use numerical analysis and statistics...and electrical engineers use simulation and modelling...I can't think of anything more directly related to the real world than a user interface...maybe you don't live in the same world that I do... |> These are all purely symbolic. They involve manipulating symbols and |> information. |> |> I like engineering. Put simply, I like building stuff. Creating a piece |> of software, though, is a lot more like writing something than building |> something. You just have a real literal-minded audience :)... What? How can you compare literature with software...their purpose is completely different. Software is the bridge between hardware and the user, not a piece of poetry... |> I thought that |> satellites, dishwashers, dialysis machines, airplanes, telecommunications |> equipment, laptop computers, relational databases, finite element analysis |> models, and, well, actually, every OTHER thing I've seen software |> used for was part of the real world. |> |> What? You mean I can wash my dishes with software? Wow. What a |> concept. A relational database is part of the real world? I thought |> it was a symbolic framework for organizing information (which is about |> as abstract as it can get). I've seen *hardware* used in the real |> world, but not software. All I've ever seen software is manipulate |> symbols. Even low-level stuff like device drivers and barcode |> scanning software... I don't see your point...if software didn't exist, we'd still be back in the 60's waiting for hardware that could do something for people...without software, hardware is moot. Why do you think microprocessors use microcode? Because building the logic isn't feasible...software allows hardware to reach its highest potential, and without it hardware development would virtually stop. |> I think I'd ask them to solve some problems. Probably have them rig |> up an interface to some device, write some queries for a database, |> reverse engineer a design from some legacy code, etc etc etc. You |> know--do some software engineering. |> |> In most engineering disciplines, tests are done by testing knowledge, |> not by testing performance. What you describe sounds more like an |> exam in art, music, or writing (usually called a "practical" or |> "recital" exam). Hmm... I wonder how that could be? |> |> Think of it as the kind of thing lawyers have to do to pass the bar, |> or doctors have to do to become doctors. |> |> Are lawyers and doctors engineers? Wow, learn something new every day :). Well let me teach you something more...an engineer is someone who builds things for people...whether software, hardware, toys, dishwashers or whatever... I'm a computer engineer, and as such a design both hardware and software. These are just tools of the trade. As for the real world, it needs both hardware and software just as I do...whether their is such a thing as hardware engineering or software engineering, it doesn't matter. Ultimately, both are done by people for people, and are used by people...Thus, whether you build software or hardware, you are still engineering...:) Daniel Filiberti dan@ece.arizona.edu [:)} ------------------------------------------------------------------------ ------- "If the world ended with a big-bang, I'd ride the waves to the edge of the universe, and fall flat on my face." +++ Big, bad, and ugly. +++ ------------------------------------------------------------------------ -------
amanda@visix.com (Amanda Walker) (04/17/91)
dan@ece.arizona.edu (Dan Filiberti) writes:
Uh, I don't think you live in the real world...people in the real
world use user interfaces...people in the real world use numerical
analysis and statistics...and electrical engineers use simulation
and modelling...I can't think of anything more directly related to
the real world than a user interface...maybe you don't live in the
same world that I do...
However, building a user interface (as the term is generally applied in
the computer industry) does not entail building something that a person
interacts with. It involves constructing a metaphor for, or a depiction
of, something that does not exist; the user then interacts with this
symbolic construct instead of interacting with the "real world". The
screen in front of me is a hunk of glass--nonetheless I interact with
it as if it were composed of several sheets of paper, terminal screens,
a mailbox, and several other things. It is this virtual quality which,
to my mind, makes software more of an art than a science. Books are
virtual reality. Music is virtual reality. A painting is virtual
reality. A tractor is not virtual reality. Now, is software more like
a book or a tractor?
What? How can you compare literature with software...their purpose
is completely different.
I disagree. The purpose of both is to allow a person to interact with
something that has no concrete existence.
without software, hardware is moot.
No, just special purpose, since its design must embody what it will be
used for.
Why do you think microprocessors use microcode? Because building
the logic isn't feasible...
What about RISC designs, which tend to explicitly avoid microcode?
Software can often gain you many of the benefits of a physical
device without some of the costs of building such a device. This is
one of the main reasons it is useful. Again, it lets a person work
*as if* they had a particular tool. Emacs lets me work to large
extent as if I had the world's best typewriter, without requiring me
to actually have one.
software allows hardware to reach its highest potential,
and without it hardware development would virtually stop.
I think of it the other way around: Hardware is simply the medium through
which people can use software... In an important respect, my workstation
is the interface between me (and the real world I live in) and the software
I use. My tools are virtual, not physical. I can replace all of the
hardware that I use in the course of a day, and still be using the same
tools and materials, because those tools and materials are software and
data, not physical things.
Well let me teach you something more...an engineer is someone who
builds things for people...
This seems to be a much wider definition than I am used to.
Ultimately, both are done by people for people, and are used by
people...Thus, whether you build software or hardware, you are
still engineering...:)
But if building things for people defines engineering, I think that
we've wandered quite a bit from Jim's version of "engineering," or
the definitions that seem prevalent in industry. By your definition,
a sculptor is an engineer, as is a composer, or manager, or a politician.
Now, I very much agree that all of these share characteristics and
techniques with engineering, but I would nonetheless hestitate to call
all of them "engineers." To do so would make the term almost
meaningless.
--
Amanda Walker amanda@visix.com
Visix Software Inc. ...!uunet!visix!amanda
--
"I used to be Snow White, but I drifted." ---Mae Westdan@ece.arizona.edu (Dan Filiberti) (04/17/91)
In article <1991Apr16.171011.14050@visix.com>, amanda@visix.com (Amanda Walker) writes: |> However, building a user interface (as the term is generally applied in |> the computer industry) does not entail building something that a person |> interacts with. It involves constructing a metaphor for, or a depiction |> of, something that does not exist; the user then interacts with this |> symbolic construct instead of interacting with the "real world". The |> screen in front of me is a hunk of glass--nonetheless I interact with |> it as if it were composed of several sheets of paper, terminal screens, |> a mailbox, and several other things. It is this virtual quality which, |> to my mind, makes software more of an art than a science. Books are |> virtual reality. Music is virtual reality. A painting is virtual |> reality. A tractor is not virtual reality. Now, is software more like |> a book or a tractor? Wrong. I have a problem with people not interacting with a user interface, since that is the sole purpose of a user interface. And, you continue to say that the user does interact with the symbolic construct (user interface) which is it, yes or no? At its lowest level, software is not virtual. Have you ever microcoded? Microcode essentialy describes hardware connections (registers to bus, bus to memory, etc...), this is not virtual reality, unless hardware is virtual reality. At its lowest level, a file system at some point writes its data to hardware, is that virtual reality, no. Software is definitely more like the tractor. Literature only affects the mind of the reader, while software directly affects hardware. Please, give me an example of one computer system that didn't benefit in some way from a software generated user interface...just one. |> What? How can you compare literature with software...their purpose |> is completely different. |> |> I disagree. The purpose of both is to allow a person to interact with |> something that has no concrete existence. Computer hardware has no concrete existence, boy you really don't understand, do you? |> without software, hardware is moot. |> |> No, just special purpose, since its design must embody what it will be |> used for. Is a computer system special purpose? Please, show me a computer that was designed without the aid of software along the way... |> Why do you think microprocessors use microcode? Because building |> the logic isn't feasible... |> |> What about RISC designs, which tend to explicitly avoid microcode? At the expense of a reduced instruction set, meaning more software to make it do anything. |> I think of it the other way around: Hardware is simply the medium through |> which people can use software... In an important respect, my workstation |> is the interface between me (and the real world I live in) and the software |> I use. My tools are virtual, not physical. I can replace all of the |> hardware that I use in the course of a day, and still be using the same |> tools and materials, because those tools and materials are software and |> data, not physical things. Since when is data not physical. Have you ever heard of RAM? How about registers? I`d really like to see you swap hardware while using exactly the same software on the new machine, and get anything to run. As soon as you change some of the hardware, the software changes with it. It might be at a low level, such as the operating system, compilers, file system, and other low level code, but its software just the same. |> Well let me teach you something more...an engineer is someone who |> builds things for people... |> |> This seems to be a much wider definition than I am used to. Well, maybe you'll be used to this definition. Software engineering - the application of knowledge obtained through study and practice of writing software. How's that? Daniel Filiberti dan@helios.ece.arizona.edu [:)} ------------------------------- "I sing the body electric...what a shock!" -------------------------------
amanda@visix.com (Amanda Walker) (04/18/91)
In article <1991Apr16.133304@ece.arizona.edu> dan@ece.arizona.edu (Dan
Filiberti) writes in annoyingly poorly word-wrapped fashion:
Wrong. I have a problem with people not interacting with a user
interface, since that is the sole purpose of a user interface.
You are missing my point. I am distinguishing between a physical
construct and a symbolic one. What I think of as "engineering" is the
application of the physical sciences (principally physics and chemistry,
but not exclusively) to the construction of physical devices (or "engines,"
hence the term "engineer"). This interpretation is supported by the
dictionary definition you yourself cited.
By this definition, designing and building a computer is engineering.
Writing a program is not; it does not involve the application of the
physical sciences, although it may sometimes involve application of
mathematics.
A user interface is not a physical device, like an automobile is. It is
a symbolic construct that has no meaning beyond that assigned to it by
a person observing or interacting with it. Think about it.
Have you ever microcoded?
Yup. Hands-on experience with AMD 2901 and 2903 bit slice machines, as
well as familiarity with other microcoded architectures.
Microcode essentialy describes hardware connections (registers to
bus, bus to memory, etc...), this is not virtual reality, unless
hardware is virtual reality.
Microcode is nothing *but* the creation of virtual reality. The whole
idea of it is that you can build a processor with a specific virtual
architecture without having to design and build it in hardware. A microcoded
control unit lets you act as if you had a hardwired control unit without
incurring some of the costs of building one. Look at a 68000 and a 68040.
The 68000 is mostly done in microcode, which lets the hardware be a lot
simpler. That hardware can instatiate many other virtual architectures,
depending on the microcode. It can be a 68000, or part of an IBM 370,
or whatever. A 68040 is mostly hardwired. It's faster, but the hardware
is a lot more complex and a lot more dedicated to a particular architecture.
Software conveys a virtual reality in terms of physical reality. I view
this as directly analogous to the way a novel, or a play, or a movie
implements a virtual experience in terms of an actual experience. When
I went to see "She Stoops To Conquer" last week, I didn't *actually* visit
the 18th century British Isles, but I nonetheless had some of the experience
of them. Likewise, my screen doesn't *actually* have a sheet of paper upon
which I am typing this article, but I nonetheless have some of the experience
of it.
At its lowest level, a file system at some point writes its data to
hardware, is that virtual reality, no.
Yes. Do you tell your computer how to orient the magnetic domains in the
media on your disk? No. You interact with a symbolic construct
called a "file system" which creates a virtual reality in terms of those
magnetic domains.
Please, give me an example of one computer system that
didn't benefit in some way from a software generated user
interface...just one.
An analog guidance system. A step-by-step telephone switch. I could go
on...
Computer hardware has no concrete existence, boy you really don't
understand, do you?
Nope, you don't understand. I've tried to ex
Is a computer system special purpose?
Some, yes.
Please, show me a computer
that was designed without the aid of software along the way...
Any analog or pre-Von Neumann computer. I gave a couple of examples
above. An old-fashioned electronic calculator chip.
However, how it was designed is immaterial--very few things are
designed without the aid of software these days :).
At the expense of a reduced instruction set, meaning more software to
make it do anything.
OK, take a non-microcoded processor, like the Z80 or the 6502. My point
stands. You can always trade off special-purpose hardware for software.
Since when is data not physical. Have you ever heard of RAM? How
about registers?
Since when are RAM and registers data? Sigh.
I`d really like to see you swap hardware while using exactly
the same software on the new machine, and get anything to run.
I did it Monday. Same Emacs, same window manager, same Usenet, ...
Software engineering - the application of knowledge obtained through
study and practice of writing software.
How's that?
Not bad, but it violates your own definition of engineering. It is, however,
what I use as a colloquial definition, and why my business card says
"software engineer."
Actually, my colloquial definition is closer to:
Software engineering - the application of formalized knowledge obtained
through study and practice of writing software.
I still think it's a misnomer.
--
Amanda Walker amanda@visix.com
Visix Software Inc. ...!uunet!visix!amanda
--
"There are two ways to write bug-free code; only the third way works."
--unknown consultantdan@ece.arizona.edu (Dan Filiberti) (04/18/91)
In article <1991Apr17.172806.23036@visix.com>, amanda@visix.com (Amanda Walker) writes: >In article <1991Apr16.133304@ece.arizona.edu> dan@ece.arizona.edu (Dan> Filiberti) writes in annoyingly poorly word-wrapped fashion: I'll try to fix that, damn editors... :) >>Wrong. I have a problem with people not interacting with a user >>interface, since that is the sole purpose of a user interface. >You are missing my point. I am distinguishing between a physical >construct and a symbolic one. What I think of as "engineering" is the >application of the physical sciences (principally physics and chemistry, >but not exclusively) to the construction of physical devices (or "engines," >hence the term "engineer"). This interpretation is supported by the >dictionary definition you yourself cited. >By this definition, designing and building a computer is engineering. >Writing a program is not; it does not involve the application of the >physical sciences, although it may sometimes involve application of >mathematics. Unfortunately, while your defn is supported, its not the only one. I'll admit that writing a program does not necessarily apply natural science (which I think is what you mean by physical sciences, etc), but the primary defn of science is the following: science - knowledge attained through study or practice Also, you're wrong. By your defn, designing a computer is NOT engineering. Sorry. Hardware designers hardly ever deal with the construction of devices on a physical science level. They symbollically represent the internal architecture of a computer, using CAD. Please point out the difference between working with symbols of "and" gates, etc...and microcode. That's right, the only difference is a difference in symbols and terms. In fact, by your defn, you could prob eliminate over half the fields in electrical engineering... >A user interface is not a physical device, like an automobile is. It is >a symbolic construct that has no meaning beyond that assigned to it by >a person observing or interacting with it. Think about it. Sure, I'll think about it. No matter who chooses "save" from the Mac file menu, a file gets saved to disk. That's the meaning of "save", whether the user thinks the computer is a brain and remembers his information, or thinks the computer etches the information in stone. The meaning doesn't change from the hardware's point of view...and that's all that counts. >>Have you ever microcoded? >Yup. Hands-on experience with AMD 2901 and 2903 bit slice machines, as >well as familiarity with other microcoded architectures. >>Microcode essentialy describes hardware connections (registers to >>bus, bus to memory, etc...), this is not virtual reality, unless >>hardware is virtual reality. >Microcode is nothing *but* the creation of virtual reality. The whole >idea of it is that you can build a processor with a specific virtual >architecture without having to design and build it in hardware. A microcoded >control unit lets you act as if you had a hardwired control unit without >incurring some of the costs of building one. How do you build a processor with "virtual architecture", and then not build it in hardware? Whether microcoded or hardwired, a control unit is a control unit is a control unit. You are trying to define a microcoded control unit as an abstraction from a hardwired control unit. Wrong! They are just different implementations of the SAME THING. The microcoded unit uses a ROM (hardware) and addressing to send the control signals. The hardwired unit uses digital logic...but they both accomplish the same thing, through hardware. And, the microcode you write is stored in the ROM as a physical reality... >Software conveys a virtual reality in terms of physical reality. I view >this as directly analogous to the way a novel, or a play, or a movie >implements a virtual experience in terms of an actual experience. When >I went to see "She Stoops To Conquer" last week, I didn't *actually* visit >the 18th century British Isles, but I nonetheless had some of the experience >of them. Likewise, my screen doesn't *actually* have a sheet of paper upon >which I am typing this article, but I nonetheless have some of the experience >of it. And, a civil engineer doesn't actually pound the nails, but is still an engineer. What's your point? How many engineers actually solder the parts of a computer together? *laugh* >>At its lowest level, a file system at some point writes its data to >>hardware, is that virtual reality, no. > Yes. Do you tell your computer how to orient the magnetic domains in the > media on your disk? No. You interact with a symbolic construct > called a "file system" which creates a virtual reality in terms of those > magnetic domains. Wrong. At its lowest level, there is always some software that controls the writing of the data onto the media. Sure, its probably embedded in the disk drives controller. >>Please, give me an example of one computer system that >>didn't benefit in some way from a software generated user >>interface...just one. >An analog guidance system. A step-by-step telephone switch. I could go > on... Please do, since neither one of these examples is a computer. Since when can a telephone switch be programmed and store, retrieve and process data? >> Is a computer system special purpose? > Some, yes. Although computers can be programmed for a special purpose, they are not usually specifically designed with only one purpose in mind. >> Please, show me a computer >> that was designed without the aid of software along the way... >Any analog or pre-Von Neumann computer. I gave a couple of examples >above. An old-fashioned electronic calculator chip. That's pretty good. Now, please show me a computer built within the last decade that was designed without the aid of software. We would still be using that old-fashioned stuff if it wasn't for the idea of programmability. >However, how it was designed is immaterial--very few things are >designed without the aid of software these days :). I agree. Hence the term "software engineering". >>At the expense of a reduced instruction set, meaning more software to >>make it do anything. >OK, take a non-microcoded processor, like the Z80 or the 6502. My point >stands. You can always trade off special-purpose hardware for software. Yes, its theoretically possible. But, as the number of instructions increase, the ability to design the hardware is stressed. And, like I said, special-purpose hardware increases the amount of software required to do the same stuff, in most cases. >>I`d really like to see you swap hardware while using exactly >>the same software on the new machine, and get anything to run. >I did it Monday. Same Emacs, same window manager, same Usenet, ... Oh? And, there was no software differences between the two machines. I like how you conveniently left the two machines you used out, so I couldn't point out the differences in software that allowed you to run Emacs, window manager, and Usenet. If the microprocessors are different, you can start with the kernel... >>Software engineering - the application of knowledge obtained through >> study and practice of writing software. >>How's that? > Not bad, but it violates your own definition of engineering. No it doesn't. My previous defn was general, I didn't feel like pulling out the old dictionary. It violates nothing, because you can't possibly build anything for people without using learned knowledge. > I still think it's a misnomer. Well, I have no problem with it. It fits with how engineering is defined in our society today. And, that's all that counts... Daniel Filiberti dan@helios.ece.arizona.edu [:)}
jls@rutabaga.Rational.COM (Jim Showalter) (04/18/91)
>I like engineering. Put simply, I like building stuff. Creating a piece >of software, though, is a lot more like writing something than building >something. I'm a software architect. I build stuff. The actual coding part of the process is about as creative and interesting to me as driving in nails would be to a construction engineer. Interestingly, Bertrand Meyer called his book "Object-oriented Software CONSTRUCTION", not "Object-oriented Sofware Composing". Perhaps there was a reason for this?... The company I work for is essentially in the business (and successfully so) of converting software shops from artists' studios to construction sites. Why? Because construction is a pretty well understood pursuit, whereas artists tend to be rather flaky and temperamental (sp?). >In most engineering disciplines, tests are done by testing knowledge, >not by testing performance. What you describe sounds more like an >exam in art, music, or writing (usually called a "practical" or >"recital" exam). Hmm... I wonder how that could be? Would you test a hardware engineer's competence by having him answer multiple choice questions about this or that chip's gate delay? I wouldn't: I'd ask him/her to design me up a fine circuit or two. This is ALSO a practical test, and the only kind I can think of that would give me any real understanding of that engineer's competence. I see no difference between this and testing a software engineer. If the professional tests given to engineers in other disciplines are NOT practical in nature, I'm inclined to view this as a bug in the tests. -- * The opinions expressed herein are my own, except in the realm of software * * engineering, in which case I borrowed them from incredibly smart people. * * * * Rational: cutting-edge software engineering technology and services. *
ewoods@hemel.bull.co.uk (Eoin Woods) (04/18/91)
amanda@visix.com (Amanda Walker) writes: [ ... deleted ... ] >Software conveys a virtual reality in terms of physical reality. I view >this as directly analogous to the way a novel, or a play, or a movie >implements a virtual experience in terms of an actual experience. When >I went to see "She Stoops To Conquer" last week, I didn't *actually* visit >the 18th century British Isles, but I nonetheless had some of the experience >of them. Likewise, my screen doesn't *actually* have a sheet of paper upon >which I am typing this article, but I nonetheless have some of the experience >of it. [ ... deleted ...] Tell you what - why don't we call it Software Virtual Engineering !! :-) Eoin. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Eoin Woods, Software Development Group, Bull HN Information Systems, ~ ~ Maxted Road, Hemel Hempstead, Herts HP2 7DZ, UK. ~ ~ Tel : +44 442 232222 x4823 Fax : +44 442 236072 ~ ~ < Eoin.Woods@hemel.bull.co.uk or ...!uunet!ukc!brno!ewoods> ~ ~ < When do we start news group comp.os.emacs ? :-) > ~ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Eoin Woods, Software Development Group, Bull HN Information Systems, ~ ~ Maxted Road, Hemel Hempstead, Herts HP2 7DZ, UK. ~ ~ Tel : +44 442 232222 x4823 Fax : +44 442 236072 ~ ~ < Eoin.Woods@hemel.bull.co.uk or ...!uunet!ukc!brno!ewoods> ~ ~ < When do we start news group comp.os.emacs ? :-) > ~
amanda@visix.com (Amanda Walker) (04/19/91)
In article <1991Apr17.170635@ece.arizona.edu> dan@ece.arizona.edu (Dan Filiberti) writes: but the primary defn of science is the following: science - knowledge attained through study or practice That's an awfully general definition. I myself like it from a philosophical standpoint, but it covers most human activity. There are many things which I have studied and practiced, but which I would hesitate to call "science." For example: - Playing baroque music on the 'cello - Cooking Szechuan food - Speaking French or Japanese - Mediaeval manuscript illumination And so on. The word "science" usually carries some connotations which restrict its applicability. In particular, it usually signifies the acquisition of formalized knowledge through observation and experimentation. Now, I have taken scientific approaches to aspects of all of the above-metioned subjects, but I would still not call them scientific endeavors. Also, you're wrong. By your defn, designing a computer is NOT engineering. Sorry. Hardware designers hardly ever deal with the construction of devices on a physical science level. Funny, the hardware engineers I have worked with seem to do wire wrapping, figure out where to put decoupling caps, use oscilloscopes to look at signal levels and quality, etc. Seems pretty close to the physical level to me. Granted, there's always *some* level of abstraction involved in any activity that involves humans beings :), but I think you'll agree that, say, a silicon compiler or simulator is a higher level of abstraction than a 100MHz oscilloscope... They symbolically represent the internal architecture of a computer, using CAD. Seems to me that's design, not construction, but point taken. Design is a common aspect of many different kinds of activity. Please point out the difference between working with symbols of "and" gates, etc...and microcode. That's right, the only difference is a difference in symbols and terms. Not entirely. At the microcode level, a whole set of factors is abstracted out, such as propogation delay, fanout and fanin, signal decoupling, etc. How do you build a processor with "virtual architecture", and then not build it in hardware? Simulation. Software. Microcode and something like SoftPC (which implements a virtual IBM AT on machines ranging from a Mac to a Sparcstation) are doing basically the same thing. They are implementing a virtual architecture in terms of a physical one that is quite different. I can microprogram a handful of 2900 chips so that they act like, say, a Z80, even though the actual hardware involved is completely different. How many engineers actually solder the parts of a computer together? *laugh* I've done it... Please do, since neither one of these examples is a computer. Since when can a telephone switch be programmed and store, retrieve and process data? That's what happens when you place a call, after all... If you are now claiming that "computer" can only mean "stored program computer," I beg to differ. Software was invented after computers were. Von Neumann's innovation was important, but it is not what constitutes "computing." That's pretty good. Now, please show me a computer built within the last decade that was designed without the aid of software. How is this relevant? I can't even show you an *automobile* built within the last decade that was designed without the aid of software. All this says is that software is extremely useful, not whether or not its construction is "engineering..." >However, how it was designed is immaterial--very few things are >designed without the aid of software these days :). I agree. Hence the term "software engineering". Wouldn't that be "engineering software?" 1/2 :-) Oh? And, there was no software differences between the two machines. Very few. None from an operational point of view... I like how you conveniently left the two machines you used out, Sparcstation IPC and a DECstation 3100. so I couldn't point out the differences in software that allowed you to run Emacs, window manager, and Usenet. These differences are invisible at the level at which I interacted with the software--the software presents me with the same virtual reality (well, OK, modulo a small difference in screen size). This is part of my point: for at least a large set of actions, the hardware architecture is irrelevant. No it doesn't. My previous defn was general, I didn't feel like pulling out the old dictionary. It violates nothing, because you can't possibly build anything for people without using learned knowledge. Well, OK, if "applying learned knowledge" constitutes engineering, then I'll cede the point: just about everything I do is engineering, then. Well, I have no problem with it. It fits with how engineering is defined in our society today. And, that's all that counts... Must be a different society. Maybe is a coastal thing :)... -- Amanda Walker amanda@visix.com Visix Software Inc. ...!uunet!visix!amanda -- "I wouldn't be surprised if the architecture of Intel's microprocessors were eventually linked to the eventual fall of mankind." --Steve Gibson
cole@farmhand.rtp.dg.com (Bill Cole) (04/20/91)
|> David Hanslip replies to the world: |> |> Sometimes the quality of postings to this newsgroup severely detract from its |> value. This thread, and a couple of others that have diverged, started a few |> weeks ago with my request for information on documenting OO systems. I was |> looking for "system" level tools. |> |> I saw no useful USENET responses though I did receive some useful snail. |> USENET responses degenerated into language wars and to the final nadir of |> "I'm proud not to be a software engineer". |> But that's the value of the group, David. You can't control the responses. If you ask a question which seems perfectly straightforward and somehow the responses don't seem to have anything to do with the question, then you've obviously struck a nerve. I'll apologize for not sticking to your point, but I don't think an apology for wandering off into an important discussion is needed. /Bill
jjc@aeg.dsto.oz.au (John Cranwell) (04/20/91)
jls@rutabaga.Rational.COM (Jim Showalter) writes: >body not relevant Sometimes the quality of postings to this newsgroup severely detract from its value. This thread, and a couple of others that have diverged, started a few weeks ago with my request for information on documenting OO systems. I was looking for "system" level tools. I saw no useful USENET responses though I did receive some useful snail. USENET responses degenerated into language wars and to the final nadir of "I'm proud not to be a software engineer". I'm beginning to wonder whether those who may be able to make an intelligent and useful response are too busy engineering software to waste their time with eletronic news. Software engineering is the application of sound engineering principles and engineering rigor and discipline to the development of software. Anyone who doesn't consider him or herself to be a software engineer is playing with toy software and should keep right away from any software that my life or fortunes may have to depend on - aerospace applications, medical applications, financial applications, defense applications etc. David C. Hanslip E-mail: dch@aeg.dsto.oz.au Aeronautical Research Laboratory Phone: +61 8 259 5792 DSTO Salisbury, South Australia Fax: +61 8 259 5507
jeff@hilbert.uucp (Jeff Freedman) (04/23/91)
In article <jls.671952600@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: >The company I work for is essentially in the business (and successfully >so) of converting software shops from artists' studios to construction >sites. Why? Because construction is a pretty well understood pursuit, >whereas artists tend to be rather flaky and temperamental (sp?). ^^^^^^^^^^^^^^^^^^^^^^^ Here we see the real reason why so many employers want their software developers to be "engineers". Engineering is more predictable than art; and the people involved are more comparable in their abilities, and easier to manage. Of course, wishing for something doesn't make it so. -- Jeff
jeff@hilbert.uucp (Jeff Freedman) (04/23/91)
In article <jls.671952600@rutabaga> jls@rutabaga.Rational.COM (Jim Showalter) writes: > >I'm a software architect. I build stuff. The actual coding part of >the process is about as creative and interesting to me as driving in >nails would be to a construction engineer. Architects don't pound nails; they draw things, either using pencil-and-paper, or a CAD program. And they think of themselves, at least in part, as artists. Construction engineering is an entirely different field. BTW, I don't dispute that software development has some aspects of engineering. Most programmers are happy to use an existing block of code that does what they need, or a new tool that will help them organize their designs. But much of what we do involves the creation of something new: a friendlier interface, a new language, perhaps a whole new use for a computer. Otherwise, our employers wouldn't be willing to spend so much money on us! And it is this creative process that goes beyond engineering, and that becomes art. You compare "pounding nails" to writing code. But building is a lot more than hammering nails. It can involve the design and creation of custom mouldings, windows and doors. If not an art, it certainly can be considered a craft. I think of software the same way; I love writing it, and enjoy finding ways to make the code faster, or shorter, or easier to understand. Note that Fischer and LeBlanc named their book "Crafting a Compiler". -- Jeff
mjl@cs.rit.edu (Michael J Lutz) (04/23/91)
[My initial posting does not seem to have made it outside of Western NY. My apologies if you've seen this already - mjl ] This is from an ongoing debate in comp.object, but I thought it might be of interest to comp.software-eng readers as well - mjl In article <1991Apr17.172806.23036@visix.com>, amanda@visix.com (Amanda Walker) writes: |> ... I am distinguishing between a physical |>construct and a symbolic one. What I think of as "engineering" is the |>application of the physical sciences (principally physics and chemistry, |>but not exclusively) to the construction of physical devices (or "engines," |>hence the term "engineer"). This interpretation is supported by the |>dictionary definition you [a previous writer] cited. Dictionarys aren't always the best source of information when it comes to technical terms. In particular, if we buy the notion that engineering is concerned with the construction of physical devices, what is to become of the Industrial Engineer? As far as ABET is concerned, this is an ``engineering discipline'', but IE's are not directly involved in the design or manufacture of physical devices; instead, they are most concerned with the processes underlying these activities -- and this is at least as abstract as software development. As I am not an engineer by education, I decided that the best way to find out what engineering is all about was to find out what *engineers* say engineering is all about. This is a meta-question -- we have to separate what an engineer does from the specific tools he or she uses in addressing engineering problems. The problem is compounded by the fact that engineering typically attracts goal-oriented, precise, quantitative persons who are not particularly introspective about what they do and where engineering fits in the grand scheme of things. However, there are some exceptions (thank God). I strongly recommend each of the following to those who want to join debate over what engineering is and whether software development is, can be, or should be an engineering discipline: Shaw, Mary "Prospects for an Engineering Discipline of Software", IEEE Software, Vol. 7 No. 6 (Nov. 1990). Florman, Samuel C. Existential Pleasures of Engineering. St. Martin Press, 1976. Petroski, Henry. To Engineer is Human : The Role of Failure in Successful Design. St. Martin's Press, 1985 Koen, Billy Vaughn. Definition of the Engineering Method. American Society for Engineering Education, 1985 For the record: Mary Shaw is on the computer science faculty at Carnegie-Mellon; she also is involved with at the Software Engineering Institute. Florman is a civil engineer, and I believe Petroski is as well (if not, Petroski is a mechanical engineer). Koen is a chemical engineer by training, but also has held positions in mechanical engineering departments. I believe he is still at U.T. Austin. Koen's book (actually a pamphlet, costing about $7.00) has influenced me greatly because: a) he writes lucidly and persuasively, b) the publication is from the ASEE, and I'm an educator, c) the fact that the ASEE publishes and actively promotes the pamphlet in its magazines indicates that at least a few engineers in positions of influence believe Koen has something important to say. --------- Mike Lutz Rochester Institute of Technology Rochester, NY 14623-0887 mjl@cs.rit.edu
philbo@dhw68k.cts.com (Phil Lindsay) (04/24/91)
> >Software engineering is the application of sound engineering principles and >engineering rigor and discipline to the development of software. Anyone who >doesn't consider him or herself to be a software engineer is playing with toy >software and should keep right away from any software that my life or >fortunes may have to depend on - aerospace applications, medical applications, >financial applications, defense applications etc. > >David C. Hanslip E-mail: dch@aeg.dsto.oz.au >Aeronautical Research Laboratory Phone: +61 8 259 5792 >DSTO Salisbury, South Australia Fax: +61 8 259 5507 I hope Mr. Hanslip can elaborate on what "sound engineering principles" are in respect to Computer Science. Why must software metrics be tied to something called "software engineering?" David's remarks seem a little egocentric and presumptuous; I hope this is not the norm for people who choose to call themselves "software engineers." Most people would like to see software development legitimatized. The industry is using the term "software engineering" for this means. The truth is that there is no such thing as "software engineering." Of course, when there is money to be made and people to impress...Anything is possible. -- Phil Lindsay - "Patents threaten future technology" Internet: philbo@dhw68k.cts.com Phone: Wrk7143852311 Hm7142891201 UUCP: {spsd,zardox,felix}!dhw68k!philbo USMAIL: 152A S. Cross Creek Rd, Orange, Ca. 92669
dan@ece.arizona.edu (Dan Filiberti) (04/24/91)
In article <1991Apr18.230252.3299@visix.com> amanda@visix.com (Amanda Walker) writes: >> but the primary defn of science is the following: >> science - knowledge attained through study or practice >That's an awfully general definition. I myself like it from a philosophical >standpoint, but it covers most human activity. There are many things >which I have studied and practiced, but which I would hesitate to call >"science." For example: > - Playing baroque music on the 'cello > - Cooking Szechuan food > - Speaking French or Japanese > - Mediaeval manuscript illumination HaHaHa! [:)} Sorry, I just can't let these "examples" sneak by... I really doubt that anyone would argue that music doesn't involve both art (skill) and science (theory). Same with food preparation, unless you always eat fast food. Maybe you are confusing "art" with "science". Speaking a foreign language is an "art", it involves skill, it is the product of a "science", learning the grammar, etc, of the language. I don't know about the last one, never heard of it, but it probably involves science also. >And so on. The word "science" usually carries some connotations which >restrict its applicability. In particular, it usually signifies the >acquisition of formalized knowledge through observation and >experimentation. Now, I have taken scientific approaches to aspects >of all of the above-metioned subjects, but I would still not call them >scientific endeavors. "observation and experimentation" sounds a lot like "study and practice" to me. How can you take a "scientific approach" and not call what you learn "science"? >>Also, you're wrong. By your defn, designing a computer is NOT >>engineering. Sorry. Hardware designers hardly ever deal with the >>construction of devices on a physical science level. >Funny, the hardware engineers I have worked with seem to do wire wrapping, >figure out where to put decoupling caps, use oscilloscopes to look at >signal levels and quality, etc. Seems pretty close to the physical >level to me. >>They symbolically represent the internal architecture of a computer, >>using CAD. >Seems to me that's design, not construction, but point taken. Design is >a common aspect of many different kinds of activity. I'm getting tire of this runaround stuff. Is a hardware designer an engineer or not? Is someone who spends 5 yrs in college earning an electrical engineering degree, and then designs logic using CAD (with no physical level involvement) known as an "engineer"? My answer is yes... >>Please point out the difference between working with >>symbols of "and" gates, etc...and microcode. That's right, the >>only difference is a difference in symbols and terms. >Not entirely. At the microcode level, a whole set of factors is abstracted >out, such as propogation delay, fanout and fanin, signal decoupling, etc. These factors are not "abstracted out". They don't exist. Abstraction involves "information hiding", you can't hide what doesn't exist. The difference at a low level is implementation, the difference at a high level is in symbols and terms. Digital logic designers worry about "fan out", etc.. but they don't create the IC's that implement their logic. >Microcode is nothing *but* the creation of virtual reality. The whole >idea of it is that you can build a processor with a specific virtual >architecture without having to design and build it in hardware. A >>How do you build a processor with "virtual architecture", and then not >>build it in hardware? >Simulation. Software. Microcode and something like SoftPC (which >implements a virtual IBM AT on machines ranging from a Mac to a >Sparcstation) are doing basically the same thing. They are implementing >a virtual architecture in terms of a physical one that is quite different. >I can microprogram a handful of 2900 chips so that they act like, say, >a Z80, even though the actual hardware involved is completely different. Why do you twist everything around, and put my statements out of context? I agree that you can program virtual architecture, in fact I've used some, but the issue is not microprogramming. The issue is microcode! Microcode is not the creation of virtual reality. I'd like to see you microcode a 6502 processor to act like a 68000. You can't, because microcode is intimately tied to the hardware implementation. Can you microcode the 6502 to accept the 68000 instruction set? No. >That's what happens when you place a call, after all... If you are now >claiming that "computer" can only mean "stored program computer," I beg >to differ. Software was invented after computers were. Von Neumann's >innovation was important, but it is not what constitutes "computing." Give me a break. Talking about general defns. I guess I am a computer! >>That's pretty good. Now, please show me a computer built within the >>last decade that was designed without the aid of software. >How is this relevant? I can't even show you an *automobile* built within >the last decade that was designed without the aid of software. All this >says is that software is extremely useful, not whether or not its >construction is "engineering..." It is very relevant. I'm trying to point out the importance of software, and its rapid increase of design complexity. This is what makes "software engineering". >Wouldn't that be "engineering software?" 1/2 :-) mmmmmmmm, ok 1/2. >These differences are invisible at the level at which I interacted with >the software--the software presents me with the same virtual reality (well, The fact is, a "software engineer" had to create that virtual reality. Are the people who write SunOS and VMS "software engineers" while those who write Emacs, etc not? The OS is not virtual reality, but it is still software, isn't it? Are you trying to make a distinction between levels of programming, like applications, operating systems, compilers, etc... or what? >Well, OK, if "applying learned knowledge" constitutes engineering, then >I'll cede the point: just about everything I do is engineering, then. That's right, but that isn't what makes you an engineer. It's the quality and quantity of knowledge that you possess. People make you an "engineer" by the way they observe you applying your knowledge. If I design and build a shed, I am essentially civil engineering, but people don't call me a "civil engineer". Who knows, but like I said, I have no problem with someone putting the label "software engineer" on their card. I'm not going to hire them for their title, but for experience, reputation, etc... Daniel Filiberti dan@helios.ece.arizona.edu [:)} ------------- Sorry, this reply is late. I was on vacation... -------------