soft-eng@MITRE.ARPA (05/24/88)
Date: Sat, 21 Apr 88 17:15:23 EDT
From: Soft-Eng
Reply-To: Soft-Eng@mitre.arpa
Subject: Soft-Eng Digest V1 #4
To: nigam@mitre.arpa
Soft-Eng Digest Sat, 21 Apr 88 V: Issue 4
Today's Topics:
MS in SE or CS (2 msgs)
Posessive programming (2 msgs)
Style rules for C shops (3 msgs)
Wang Institute Closed (4 msgs)
----------------------------------------------------------------------
Date: 29 Apr 88 21:41:35 GMT
From: uw-entropy!dataio!pilchuck!ssc!happym!polari!b-mrda!fletcher@june.cs.washington.edu ( Justin Fletcher )
Subject: MS in SE or CS
I should first point out that I'm 'one of those guys' with an unrelated
degree. I have had the good fortune to discover from working with a
number of very good people that the degree itself meens nothing. People
fresh out of school still need major amounts of training to become accustomed
to the real world and to gain experience working on products that must
1. work and 2. be supportable. The importance of supportable comes best
from doing that support for a while -- its need becomes self-evident.
My conclusions from a few years of working with and even hiring programmers
is that I don't really care about the degree (I don't even care if they've
got one) but I do care about the experience.
Yes, people still fresh out of school are (and should) be hired. They
have the latest techniques and methods (I hope) but I still prefer
an individual with experience (whatever the degree) to play a key role
in product development.
------------------------------
Date: 4 May 88 22:54:11 GMT
From: pixar!unicom!jonson@ucbvax.Berkeley.EDU (Mary D Johnson)
Subject: MS in SE or CS
In article <6300001@b-mrda.UUCP> fletcher@b-mrda.UUCP ( Justin Fletcher ) writes:
>I should first point out that I'm 'one of those guys' with an unrelated
>degree. I have had the good fortune to discover from working with a
>number of very good people that the degree itself meens nothing.
stuff deleted
>Yes, people still fresh out of school are (and should) be hired. They
>have the latest techniques and methods (I hope) but I still prefer
>an individual with experience (whatever the degree) to play a key role
>in product development.
I have found the same to be true after working in both the scientific
programing and 'business' applications world. The new 'kids' on the block
bring the yeast to the mix to keep us 'old' duffers on our toes.
The only problem I have run into is when the youngsters want to do all
the new exotic stuff, and haven't done some of the maintenance work that
they are usually hired to do (since no one else wants to do it).
Also found it hard to convince scientific (FORTRAN) types that they needed
to learn some of the other languages if they wanted to keep their jobs
when the company had to start doing design and maintenance work in the
area of business applications.
------------------------------
Date: 28 Apr 88 12:27:59 GMT
From: mcvax!ukc!stl!stc!datlog!dlhpedg!cl@uunet.uu.net (Charles Lambert)
Subject: Posessive programming
In article <1066@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse)
writes on the subject "Style rules for C shops":
>... the only case where one person should work on another person's
>code is when the responsibility for that piece of code changes hands as
>well. (The "too many cooks" argument - with software, as with *most*
>other things, I believe that "too many" means "more than one".)
This disturbs me deeply; it is an advocation of ego-bound programming.
No piece of code should be "owned" by one person to the extent that nobody
else may work on it. That simply conceals and encourages idiosynchrasy,
which is the bane of maintenance. A piece of code should be common property,
and the style of it should be arbitrated by group inspection and a common
philosophy. This encourages cohesion, disseminates good idioms, and
promotes egoless programming.
------------------------------
Date: 3 May 88 01:13:47 GMT
From: mnetor!utzoo!yunexus!geac!daveb@uunet.uu.net (David Collier-Brown)
Subject: Posessive programming
In article <759@dlhpedg.co.uk> cl@datlog.co.uk (Charles Lambert) writes:
>No piece of code should be "owned" by one person to the extent that nobody
>else may work on it. That simply conceals and encourages idiosynchrasy, [sic]
>which is the bane of maintenance. A piece of code should be common property,
>and the style of it should be arbitrated by group inspection and a common
>philosophy. This encourages cohesion, disseminates good idioms, and
>promotes egoless programming.
On the other hand, egoless programming is a theory which has not
been shown to work in all cases. Egofull programming has been a
commercial and technical success in several widely-discussed cases.
One of the most accessible examples was the development of the
Honeywell CP/6 operating system, which succeeded despite corporate
demands that it be written according to corporate standards in GMAP
(an assembler) was actually written in a modern language (PL/6) and
by a team where crosstraining was common, but individuals were
strictly responsible for "their part", and were encouraged to do a
good, if non-standard job.
CP/6 is popular with a significant minority of the customer base,
really quite elegant, and rather well-written. The PL/6 language late
became a corporate standard.
Public source: datamation.
------------------------------
Date: 29 Apr 88 10:37:01 GMT
From: hpda!hpcupt1!hpisod2!decot@ucbvax.berkeley.edu (Dave Decot)
Subject: Style rules for C shops
> Unless we intend
> to be chained to any software we write forEVER we better learn to live
> with style guidelines that lower these costs for our employers.
I have always thought that insisting that the author support his own
software forEVER would lead to much better programming practices and
higher maintainability... :-)
------------------------------
Date: 5 May 88 17:33:31 GMT
From: mcvax!enea!tut!santra!news@uunet.uu.net (news)
Subject: Style rules for C shops
In article <3850009@wdl1.UUCP> rion@wdl1.UUCP (Rion Cassidy) writes:
>>Nassim Bouteldja wrote:
>>I have had to think about this issue for a company that practices
>>programming-in-the-large (over 2 million lines of hll source code) with
>>the software having a long lifetime (>= 10 years). In an environment
>>like this, where the readability (hence maintainability) of programs is
>>of paramount importance, I would not hesitate to promote style rules
>>if I was convinced that they improve readability.
>I can't claim a great deal of experience in this vien, but it seems to
>me that if you're producing that much code that has to be maintained
>for that long of a period, you should be doing code reviews,
>walkthroughs, or inspections as part of the implementation process
>simply to assure the correct functionality.
We certainly do have code reviews, but we would like to concentrate on
the logical design of the program. It is a bit time-consuming to start
checking on line lengths, procedure lengths, amount of spaces per line,
amount of blank lines, identifier lengths. It can nicely be implemented
as a program that produces metrics on these characteristics. I actually
built such a program and by just glancing at the results of the analysis
I can identify aspects that need closer physical checking. Because
code reviews are done before system testing, it is inevitable that the
tested and validated programs will differ from the ones submitted at
code review meetings. Therefore, it is worthwhile running the style
metrics before allowing a program to be frozen in the project database.
Furthermore, when a program's life is long, it tends to be modified
along the way either to correct errors or for enhancement purposes. Often,
these kind of activities are not subject to code review checks. So my tool
can be used in those circumstances too, and in general to monitor one
aspect of software quality.
------------------------------
Date: 5 May 88 15:04:12 GMT
From: hpda!hp-sde!hpfcdc!hpldola!winter@ucbvax.Berkeley.EDU (Kirt Winter)
Subject: Style rules for C shops
In my just completed MS work at Oregon State, I looked into the possibility of
doing a truly flexible prettyprinter. I'll summarize some of the things I
learned.
In particular, I chose to look at syntactic style (where should this keyword/
construct be placed relative to anoter). Once you decide that flexibility is
necessary, the next question is how one goes about specifying his/her style
to the prettyprinter.
In the prototype I constructed (works with standard Pascal and Turbo 3.0
dialect) you give it a "style sample". This can either be done by modifying
a sample program that I provided (or giving a different sample program that
you have already written), giving that sample to the prettyprinter, and use a
command-line option that tells the prettyprinter to "learn".
The prototype (while not bug free) does a nice job of capturing the vast
majority of syntactic styles given to it. It could easily be modified to
capture more (at least by me, it's a little "hackish" right now).
I do plan (sometime, I just started a new job) to do a C version sometime
in the future. I guess if there is sufficient interest/market, I might get
around to it sooner. I have also been told of a flexible prettyprinter for
the Logitech Modula II compiler (I think it is now included with it).
What it doesn't do is do any modification of keywords, identifiers, etc. If
this is a big requirement, it is easy to add, it just didn't fall in line
with my MS work, and I had a job waiting so...
We've thought about several possible uses for it, and I'll just list a few
of them here:
- Would allow for "company standards" as well as individual taste.
(you could change company style to your style to someone else's
and back)
- Use the produced "style files" (in the learn phase) to measure
deviation from standards.
- In the academic world, use "style files" to identify authorship.
(studies have shown that current metrics, including Barry &
Meekings style measure, aren't useful for this task)
- Use it as a research tool to decide what (if anything) in syntactic
style makes a style "good" for comprehension, or how one's style
evolves over time (and perhaps how much that correlates with a
person's proficiency with a particular language).
If anyone is interested, I can provide you with some more details. If I
get a lot of interest, I'll post a longer discussion to the net.
------------------------------
Date: 26 Apr 88 14:12:00 GMT
From: apollo!scofield@eddie.mit.edu (Cary Scofield)
Subject: Wang Institute Closed
In article <5214@aw.sei.cmu.edu> maa@sei.cmu.edu (Mark Ardis) writes:
>
>>wlp@calmasd.GE.COM (Walter L. Peterson, Jr.) wrote:
>>1. Wang Institute, Tyngsboro, MA (although I had heard rumors that
>>that program might be terminated )
>
>Wang Institute was closed last August. The property was sold to
>Boston University, who decided not to continue the MSE program. Two
>former WIGS faculty will be reporting on the status of new programs
>that they are starting at the 1988 SEI Conference on Software
>Engineering Education (April 28 and 29 in Fairfax, VA).
>
I feel a correction is in order: I should like to point out that some
aspects of the Wang Institute MSE program IS being continued under the
auspices of another former WIGS faculty member at Boston University.
In fact, several of the Boston area WIGS students who were caught in
the "changeover" are now continuing their graduate software
engineering degree work at B.U.
Basically speaking, about half of the WIGS MSE program has been merged
in with half of the BU MSSE program. The curriculum leans heavily in
favor of real-time systems design. From the WIGS curriculum there are
courses in Formal Methods, Software Engineering Methodologies,
Requirements Analysis, Software Project Management, and the Software
Engineering Project. From the BU curriculum are courses on Switching
Theory, Computer Architecture, and Embedded Real-time Systems
Development, among others. Missing, unfortunately, is the one of
the very-useful WIGS core courses entitled "Management Concepts".
Can't have everything, I guess!
For further info, contact:
Dr. John Brackett
Boston University
College of Engineering
44 Cummington St.
Boston MA 02215
(617) 353-5898
------------------------------
Date: 3 May 88 19:44:13 GMT
From: hpda!hpwala!hpanly!bliven@ucbvax.Berkeley.EDU (Andy Bliven)
Subject: Wang Institute Closed
> I just received in the mail a brochure titled "Summer Institute in
> Computer Science" from the WANG INSTITUTE OF BOSTON UNIVERSITY.
> ... I guess reports of Wang Institute's death were greatly exaggerated.
As a member of the last class to receive a diploma from the Wang Institute
of Graduate Studies, I feel obliged to chime in. Boston University now
owns the Tyngsboro campus and the rights to the name "Wang Institute". The
BU master's degree program uses parts of the curriculum developed by Wang
Institute and are continuing the Summer Institute on the Tyngsboro campus.
However the organism that was Wang Institute lives on only in that parts of
it are being used as building blocks in other institutions. Naturally the
organism was unhappy about the dissection, and I doubt that anyone involved
can speak dispassionately about it even now.
Comparing "the Wang Institute of Boston University" to "Wang Institute" is
like comparing a son to his father: they have a lot in common and the
father's reputation colors the introduction of the son, but ultimately the
son must stand on his own merit.
------------------------------
Date: 5 May 88 17:38:00 GMT
From: fad@think.com (franklin a davis)
Subject: Wang Institute Closed
The distinction between "The Wang Institute of Graduate Studies" and
"The Wang Institute of Boston University" is brought home if you call
the old phone number.
They now answer, "Boston University, Tyngsboro Campus."
------------------------------
Date: 5 May 88 03:47:12 GMT
From: milano!donner!gerhart@cs.utexas.edu (Susan Gerhart)
Subject: Wang Institute Closed
Andy's distinction between the "Wang Institute of Boston University" and
the "Wang Institute of Graduate Studies" is correct and important. I speak
as a former (1982-1985) faculty member of that institution (and organizer of
the 1985 Summer Institute) who will not see used as an item of trade the name
associated with the conscientious effort and intellectual energy of so many
students and faculty and (often forgotten) staff during the period 1981-1987.
At the time that the "Wang Institute of Graduate Studies" became the "Wang
Institute of Boston University", the Master of Software Engineering degree
program was obliterated, despite full accreditation from the official
body of higher education for New England. With that action, the faculty and
staff and some non-graduating-students scattered to the winds. As Andy
remarks, those seeds are leading to new programs at the CMU-SEI
and elsewhere, as well as many new ideas and products in the software
engineering field.
This is not to say that the reborn Summer Institute of Wang Institute (or
whatever it is - I have not received the announcement) is of no value.
It is simply important to recognize that the able organizational support
associated with the Wang Institute of Graduate Studies has been totally
replaced by, perhaps equal or more or less able, staff and environment.
It is encouraging to see that one of the seeds has settled at BU, namely
John Brackett, and that a flourishing successor, but different, program
is under development.
Put simply, the Wang Institute of Boston University occupies the facilities of
and shares the first two words of the name of the Wang Institute of Graduate
Studies. Other than that, it should be judged on its own merits and achieve its
own track record.
P.S. Frankly, I think the Wang Institute should be judged more along its
matriarchal line of contributions than its patriarchal ones at this point.
------------------------------
End of Soft-Eng Digest
******************************