Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!linus!philabs!steinmetz!othello!hallett From: hallett@othello.steinmetz (Hallett) Newsgroups: comp.sys.mac Subject: Re: Programmers and Users Message-ID: <6023@steinmetz.steinmetz.UUCP> Date: Wed, 20-May-87 10:45:31 EDT Article-I.D.: steinmet.6023 Posted: Wed May 20 10:45:31 1987 Date-Received: Sat, 23-May-87 09:39:36 EDT References: Sender: root@steinmetz.steinmetz.UUCP Reply-To: hallett@othello.UUCP (Hallett) Organization: General Electric CRD, Schenectady, NY Lines: 62 In article rs4u#@ANDREW.CMU.EDU (Richard Siegel) writes: >That's the problem. Many programmers are completely ignorant, >unaware of, or simply don't care about the people who will >be using their software. ... > ... He's an excelent programmer. >THe prob is, the applications he's doing are for scientific >research, and he has VERY LITTLE conception if the needs >and requirements of the people who will be using his software! > Then I guess that is all he will ever be is a "programmer" (As opposed to what? Read on...) This is an ever increasing problem. > >It's my belief that a programmer should have a fairly good idea >of the needs of his audience, whether he's writing a word >processor to be marketed, or whether he's writing custom, >one-shot, in-house software. ANy other way is foolishness, >and programs like MS Word suffer from this lack of vision. > >Any comments? First, as a professional software engineer, I agree with you whole-heartedly. A "programmer" is a person who writes code, nothing more and nothing less, a trivial task given the practice requiring no formal training, just some cleverness, patience and determination. A "software engineer" usually was once a programmer who received additional training in project management, requirements gathering, designing and testing. The end goal is being able to adequately implement a project in an organized manner and deliver what the user domain requires with a minimum of waste. The sad state-of-mind is that the project = writing code and if more code needs to be written, then we just throw more programmers at it. This leads to poor documentation, poor structure, inadequate testing and basically a garbled mess that cannot be maintained or improved. A properly engineered project is the exact antithesis of this state. This become increasingly obvious on larger projects (> ~100K lines), but is noticeable on smaller projects as well. The methodologies work for ANY size project. For extremely small projects and development teams, some of the formalism can be dropped; for large projects, it cannot be done without. I propose that many of you who are developers do a loose form of this methodology already; it is only common sense. Anyone interested in sources to find out more about this methodology can respond to me personally and I will provide some references. I suggest that if you wish to flame me, you send me mail. This is a Mac group and not the proper place to debate software engineering. Jeffrey A. Hallett (hallett@ge-crd.arpa hallett@desdemona.uucp) Software Technology Program General Electric Corporate Research and Development ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "The needs of the few outweigh the needs of the many" -- Kirk (STIII) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Disclaimer: My opinions do not represent my employer's, but it is his fault for giving me this thing. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~