Path: utzoo!mnetor!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!ssc-vax!dickey
From: dickey@ssc-vax.UUCP (Frederick J Dickey)
Newsgroups: comp.software-eng
Subject: Re: Cynic's Guide to Software Engineering, part 4
Message-ID: <1865@ssc-vax.UUCP>
Date: 18 Apr 88 14:54:27 GMT
References: <2677@Shasta.STANFORD.EDU> <3396@zeus.TEK.COM>
Distribution: na
Organization: Boeing Aerospace Corp., Seattle WA
Lines: 26
Keywords: Software Engineering Education
Summary: developing tools

In article <3396@zeus.TEK.COM>, karenc@amadeus.TEK.COM (Karen Cate;6291502;92-734;LP=A;60sC) writes:
> In article <2677@Shasta.STANFORD.EDU> neff@Shasta.stanford.edu (Randall Neff) writes:
> >
> >The key focus of a Masters program of software engineering should be an 
> >apprenticeship working on a real, large software project, in all phases of
> >the lifecycle myth.  I suggest that a complete software engineering programming
> Sounds great.  Personally, I would be interested in a Masters of Software
> Engineering.  The project I would like to work on would be some GOOD
> software development tools.  

The following comments are not intended to be serious criticisms of the
above, but ...

It strikes me as interesting that most of the software engineers I know would,
if given the opportunity, prefer to work on the development of SE tools rather
than work on some application program. I am certainly sympathetic to this view,
it's what I would rather do. However, it seems paradoxical to me.  The
reason why SE is called engineering is because it is supposed to be focused on
solving other peoples' problems using "engineering" techniques. Most 
customers do not view SE tools as their problem. I agree that one needs tools
to do the job, but tools seem to be used as an excuse for ignoring what
SE is all about: solving someone else's problem. Thus, I tend to view
discussions of tools (at least in the context of SE) as symptoms of a
malaise rather than elements of a solution. I also wonder sometimes if the
metaphor "tool" is the wrong metaphor.
d