NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/software/2956

Internet Message Format | 1992-07-25 | 9.1 KB

Path: sparky!uunet!gatech!concert!borg!news_server!martinc
From: [e-mail] (Charles R. Martin)
Newsgroups: comp.software-eng
Subject: Re: The origin of ``software engineering''
Message-ID: <[e-mail]>
Date: 25 Jul 92 02:50:24 GMT
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: UNC Department of Computer Science
Lines: 156
In-reply-to: [e-mail]'s message of 21 Jul 92 17:16:52 GMT

Sorry for the long delay, it's been a tough week.

In article <[e-mail]> [e-mail] (A.J.C. Blyth) writes:

   In article <[e-mail]>,
   [e-mail] (Charles R. Martin) writes:
   |>   Question: What do you define real engineering as.........................?
   |>
   |>Whatever it is that has the semantics Bertrand implicitly claimed
   |>software engineering doesn't have.

   This is a very wooly and unhelpful answer could you be more precise...?

The point is that there is this assertion that software engineering
somehow doesn't have some property of "semantics" that other forms of
engineering do (other than simply a body of centuries of experience).  I
doubt this, and at least for the purposes of this discussion deny it.  I
cannot define "real" engineering in opposition to software engineering
precisely because I deny this.  But the assertion Berttrand made and you
seem to be continuing is that there *is* some essential distinction; I'd
be pleased to see either of you describe it.

   |>   |>*All* forms of engineering share many of the problems that
   |>   |>software engineering does: poorly-defined requirements,
   |>   |>complexity, change control, cost-and-schedule, and so on.
   |>   |>*If* one finds examples of appropriate complexity -- which I
   |>   |>think means looking for examples where the number of designers
   |>   |>over the design lifecycle is comparable -- one finds all the
   |>   |>problems we're used to in software.  (See for example a recent
   |>   |>book _Skyscraper_ which I would cite better if I could find
   |>   |>the thing in my bookshelves.)  Since we usually spend our time
   |>   |>around electrical engineers, we get this subconscious image
   |>   |>that all engineering can be put into boxes in a 19 inch rack.
   |>
   |>   I agree that there are many engineering principles that software
   |>   engineering can make use of, and infact should make use of.
   |>   However are you saying that the only techniques that we need to
   |>   construct computer artifacts are engineering ones.
   |>
   |>Anyway, small grammar flame aside, I certainly don't claim that the only
   |>techniques needed to construct "computer artifacts" -- by that, BTW, do
   |>you mean software?  Sounds like it would include hardware -- are
   |>engineering ones.  But is it your claim that all the techniques used by
   |>mechanical or architectural engineers are engineering ones?

   The answer to that question all depends on what you define an engineering
   techniques to be. So what do you define an engineering technique to be..?

Again, it appears to be your assertion that there is some distinction,
which I don't agree with.  What is an "engineering technique"?  What do
you propose is a non-"engineering" technique used to construct computer
artifacts?  Or is it that we're accidently agreeing here that all
techniques used constructing a computer artifact *are* in fact
engineering techniques.

The point is that I don't claim that the only techniques needed are
"engineering techniques" for the simple reason that *I* don't know what
engineering techniques are.  But I'm strongly suspicious that if you can
draw a meaningful distinction between the engineering techniques and
non-engineering techniques in software engineering, and this distinction
doesn't make the question vacuous by being completely software or
computer dependent, then we'll find that many or most varieties of
engineering and design that are complex also have analogous distinctions.

   |>   At this point point I would like to quote form a really good
   |>   book that I can honestly recommend. It's called "Work-Oriented
   |>   Design of Computer Artifacts" and its by Pelle Ehn.

   |>   In this book in the Prologue has says : "Computers and coffee
   |>   machines are perhaps the two most striking artifacts of a
   |>   workplace today. To understand these artifacts we have to
   |>   understand how people use them. For example the coffee machine
   |>   is not just used to produce a stimulating drink; more
   |>   importantly it offers an oppertunity for people to meet, for
   |>   communication in the workplace.  Similarly, computers are not
   |>   just instrumental means of production; they also condition and
   |>   mediate social relations at work."

   |>   Any engineering process that attempts to address how and why
   |>   social relations are mediate is going to find it very hard
   |>   indeed. And try to specify the semantic's of software
   |>   engineering is thus going to involve in some way specifying the
   |>   semantics of social relations.
   |>
   |>But that is precisely what an architect or architectural designer must
   |>do; similarly for civil engineers (think about highway design).  What
   |>magical property of software do you propose that makes this more true
   |>for software?

   The Oxford English Dictionary defines the term "architect" to mean the
   designer of complex structure. Thus an architect designs a system, he/she
   does not specify the system.

Are you therefore proposing that an engineer only specifies and does not
design?  Or that an architect only designs and does not specify?
Neither can be supported by fact.

Again, if there is an assertion underlying Bertrand's original statement
at all, it must be that software engineering is in some way different
from other forms of engineering.  I don't think it can be supported in
fact; I think it is an illusion that arises from experience only in
forms of engineering that deal with limited complexity.

   In the good old days when just a few people had, or, could afford a computer
   they tended to be used as large number crunching machines. However today
   most people have computers at work and at home. With the growth of the use
   of computers they have become more accept in todays society. Today
   computers are used not only mediate social interaction but also to take
   part in social relationships.

Again, you somehow seem to be proposing that this is different from
other forms of engineering or design.  But it is not the case: many
forms of engineering must take into account, mediate, and take part in
social relationships.

   |>   With computers becomeing more widespread in their use techniques
   |>   that draw upon social conepts are becomeing required to aid the
   |>   software engineering in his/her task of system construction.
   |>
   |>   This in conculsion to all this the question is can we specify the
   |>   semantcis to social concepts and constructs. Info so then the
   |>   software engineering of today can have a semantcis defined for it.
   |>   It is my personnel belief that you can not specify the semantics
   |>   for social relationships and hence you can not define the semantcis
   |>   for software engineering today.
   |>
   |>Um, say what?  If I follow correctly, there are certainly studies that
   |>others use to try to specify the "semantics of social concepts and
   |>constructs" for example in the design of public and private spaces in a
   |>building.  Again, this is so fuzzy I can't follow what you are proposing
   |>is the magical difference.

   The point that I am attempting to make is that your posting implied that
   software engineering as a hard disapline. In this assertion I beleive
   that you are wrong and I offer the social aspects of computer science
   as evidence of my belief. You only have to look at the effectiveness
   of techniques such as DEMOS and UTOPIA to see how effective techniques
   that use social concepts can be.

I don't think so -- I think my assertion is that software engineering is
no less "hard" (I presume you mean in the sense of "hard science" rather
than "difficult") than many other forms of design that are accepted as
engineering, like civil engineering design or the design of large
aircraft or of large buildings.  It is in many ways less "hard" than,
for example, designing a circuit or (perhaps) laying out a chip.  But
we cannot limit our view of engineering to these simply because they're
what we're most likely to be familiar with.
--
Charles R. Martin/(Charlie)/[e-mail]/(ne [e-mail])
O/Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
H/3611 University Dr #13M/Durham, NC 27707/[phone]
----------------------------------------------------------------------
"I am he who walks the States with a barb'd tongue, questioning every
one I meet,/Who are you that wanted only to be told what you knew
before?/ Who are you that wanted only a book to join you in your
nonsense?"  _Leaves of Grass_ xxiii.4.