soft-eng@MITRE.ARPA (Alok Nigam) (11/07/88)
Soft-Eng Digest Sun, 6 Nov 88 V: Issue 42
Today's Topics:
ethics (2 msgs)
Lisp machines or Smalltalk?
Software Engineering Digest v5n41
Software Maintenance
Structured Editor vs. Text Editor
Wanted: Info on Full-Featured CASE Tools w/Real-Time Support
What's a PC? (What's the best environment)
----------------------------------------------------------------------
Date: 4 Nov 88 02:00:11 GMT
From: sgi!daisy!klee@bloom-beacon.mit.edu (Ken Lee)
Subject: ethics
Some activity that some software people could consider unethical:
1. being asked by your manager to do something illegal (usually white
collar crime, like lying on your expense reports)
2. violating promises/contracts with clients (this may also be illegal)
3. questionable advertising (claiming something is done when it isn't,
announcing products then not delivering, etc.)
4. working on projects that you think are immoral, even if they are
legal (you can probably think of something here)
5. working on a "moral" project for a company that does things you
think are immoral
There are probably lots of others. A good professional knows how to
identify these problems and knows what do to about them. Sometimes the
action varies from person to person, especially on the legal, but
unethical issues.
------------------------------
Date: 4 Nov 88 16:48:23 GMT
From: thorin!coggins!coggins@mcnc.org (Dr. James Coggins)
Subject: ethics
Ken's list was good; here are some rather more subtle failures of
professional ethics that occur to me:
1. Deliberately underestimate the cost/time of a project in order
to get a more favorable response in contract competition.
2. Engage in what Brooks calls "gutless estimating":
Customer: "How long will it take?"
Programmer: "When do you want it?"
Customer: "Six months from now."
Programmer: (thinking) "My estimates say 12 months minimum but the
customer can't prove that I can't finish in six months, so"
(aloud): "Sure, I can do it in six months."
3. Bait-and-switch tactics: Promise the customer what he wants and then
when it's too late to back out force the customer to accept what you
are able to produce conveniently.
4. The whole category of violations of intellectual property rights could
yield many ethical problem cases, but I do have other work to do today.
5. Fail to perform services for which you have contracted, like
software maintenance, consultation, or set-up/installation.
6. As a manager, place a subordinate in a situation he or she is not
qualified to handle (i.e. set up a scapegoat).
7. Fail to carefully design and evaluate a user interface that is
going to be forced on employees who are powerless to evaluate it or
complain about its awkwardness. You have a responsibility to your
USERS as well as to your CLIENT. A good user interface can make the
system a joy to use. A bad user interface can inflict real pain on
its users.
8. Fail to inform your client of the relative costs of features he
claims are desirable. I do not accept the dictum "The client is
always right". In many cases, the client is ignorant and needs to be
enlightened. If I am worth my pay, there should be some things I know
better than the client. It is part of my professional
responsibility to question the client's requests and to inform the
client of the relative costs of his requests.
"Yes sir, we can build a marble fireplace for your living room, but
it will cost half as much as the whole rest of the house. Are you
sure you want it that bad?"
>From Money magazine, Sept 1976, p. 48:
"Deciding what to do is toughest when you're not directly involved in
a questionable practice but you know it's going on."
In my Software Engineering course last year, I had been mentioning
ethical concerns in the context of other (usually technical) issues
through the semester. I was pleased later when I was asked by some
students to give a special lecture on ethics in software engineering.
I did, of course. What's important here is that the students
requested it. I was very pleased (even though it meant some more work
for me) that the topics I had been covering caused them to think along
those lines and ask for an hour to be devoted to ethical issues. The
discussion was lively and that turned into one of the best class
meetings all semester.
------------------------------
Date: Sat, 5 Nov 88 23:29 EST
From: Henry Lieberman <Henry@AI.AI.MIT.EDU>
Subject: Lisp machines or Smalltalk?
I consider myself expert in both. I was the first Lisp machine
user at MIT and use Lisp machines daily. I did a visiting
stint at the Parc Smalltalk group some years ago, and now
occasionally use ParcPlace ST-80 on the Mac.
Smalltalk is cleaner, more thoroughly object oriented,
and makes better use of the graphical interface, but
is, well ... small. The Lisp machine is more complex
but offers much more functionality, and is [usually]
faster. If I had to choose, I'd prefer the Lispm, but
I like Smalltalk too. I feel that both are so much
better than, say, Unix+C that it's silly to bicker between
them.
------------------------------
Date: 4 Nov 88 01:16:36 GMT
From: att!alberta!calgary!cpsc!jameson@bloom-beacon.mit.edu (Kevin Jameson)
Subject: Software Engineering Digest v5n41
For the record, the Xinotech Program Composer mentioned earlier in this
group retails in a PC version for $2250.00 US, with quantity discounts,
implementations for Vaxes, etc, etc. The glossy (and price) seem to
be heavily oriented toward ADA.
------------------------------
Date: 2 Nov 88 03:34:45 GMT
From: hpda!hpcuhb!hpsmtc1!mwatkins@bloom-beacon.mit.edu (Marvin L. Watkins)
Subject: Software Maintenance
> ... , my question
>is whether software maintenance with an object-oriented interface is
>easier than software maintenance with a function-oriented interface?
>IMHO, I would assume that it is, ...
No data points on OO maintenance, BUT ...
(... something about you get what you pay for and notes is free ...)
During new product design phases, if a feature or requirement
doesn't "fit" into the evolving design, engineers are generally
*expected* to redesign the structure to create a simple, clean architecture.
During released product design (aka maintenance), if a new requirement
doesn't "fit" into the existing design, engineers are generally
*forbidden* to redesign the structure.
(Has everybody here heard the anecdote about the comment
"They made me do it!" in an ugly patch?)
Presumably, restructuring during early design is good
but during late design is bad.
Leaving aside all the fun comments one could make here,
I paraphrase lishka's question as,
"Which design method produces programs that can have
new features introduced without major modification to their
existing structure?"
My guess? OOD.
------------------------------
Date: 5 Nov 88 18:53:40 GMT
From: dg0f+@andrew.cmu.edu (Dennis Goldenson)
Subject: Structured Editor vs. Text Editor
Whether it's a "fact that most of the research issues have been settled" is
arguable. But structure editors do indeed exist that integrate the kinds of
functionality Johnny Morris describes and more into an intuitively graceful
and often "text like" user interface.
Two environments developed at Carnegie Mellon for Pascal and the Karel the
Robot teaching language are available for the Macintosh through the Kinkos
Academic Software Exchange. Called GENIE both are intended for use in
introductory/intermediate level programming methods courses.
------------------------------
Date: 3 Nov 88 16:24:34 GMT
From: hpda!hpcuhb!hpsmtc1!byackle@bloom-beacon.mit.edu (Brad Yackle)
Subject: Wanted: Info on Full-Featured CASE Tools w/Real-Time Support
Excelerator is probably the best choice for PCs but it is not very
friendly and still single user. If you are using OS/2 then Teamwork is
the best solution for the PC since the complete feature set is
available.
For workstations, both Teamwork and IDE cover all of the bases but I
like Teamwork better. Teamwork is friendly and does a very good job at
supporting the methods for syntax and correctness checking. They have a
good strategy for team use and data base accessing. Some people like
IDE, so be it, some people like vi and some like emacs.
------------------------------
Date: 3 Nov 88 20:57:06 GMT
From: new@louie.udel.edu (Darren New)
Subject: What's a PC? (What's the best environment)
N.B., most if not all of the advantages of an integrated LISP
environment cited in the above articles are also present in
Smalltalk. Not only that, but Smalltalk runs on many different
and standard machines (Suns, Macs, ...) without change to ANY
conde (object compatible). It also supplies real structure
for your data, instead of forcing everything to look like a list.
Since everything is accessable to your code, even things like the
debugger (allowing everything cited above, including evaluation
of subexpressions, code correction and restart, ...) are all written
in Smalltalk without needing anything special in the interpreter.
Check this out before claiming LISP as the "best". I would say
"one of the best" myself.
------------------------------
End of Soft-Eng Digest
******************************