Path: utzoo!attcan!uunet!ginosko!gem.mps.ohio-state.edu!csd4.csd.uwm.edu!mailrus!cwjcc!gatech!hubcap!billwolf%hazel.cs.clemson.edu
From: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,)
Newsgroups: comp.lang.misc
Subject: Re: Non-professional programmers (was: Which language to teach first?)
Message-ID: <6330@hubcap.clemson.edu>
Date: 24 Aug 89 22:38:15 GMT
References: <5868@ficc.uu.net>
Sender: news@hubcap.clemson.edu
Reply-To: billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu
Lines: 24

From article <5868@ficc.uu.net>, by peter@ficc.uu.net (Peter da Silva):
%> Would you expect an electrical
%> engineer to design a car?  A mechanical engineer to design a microchip?
%> If not, then don't expect either one to design software either.
> 
> What about problems that are well understood by the mechanical engineer
> and poorly understood by the software engineer?  [...] Even if you have 
> the Mech E working with a CS guy to develop the program, the Mech E guy 
> is still going to have to know enough about programming to provide 
> realistic specifications and guidance. 

    The software engineer has to carefully identify all assumptions
    and check them out with the domain expert, but there is no need
    for a domain expert to have to learn programming or CS.  By the
    time the software is written, the software engineer will HAVE to
    understand the "problems" to be solved, with every bit of that 
    knowledge stated precisely to and verified explicitly by the domain
    expert.  Requirements analysis and specification is part of the 
    software engineer's job, and the subject is covered extensively 
    in software engineering texts. 
   

    Bill Wolfe, wtwolfe@hubcap.clemson.edu