rs4u#@ANDREW.CMU.EDU (Richard Siegel) (05/19/87)
In <360@sdics.ucsd.EDU>, you write:
"I know that Scott Weiner is
not an average programmer, and unaware of the concerns of
users;"
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. Example: Where I work (no names, to
protect the innocent), there's a programmer who graduated
cum laude in Computer Science. 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!
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?
-Rich
Richard M. Siegel
R-Squared Development Systems
134 Horseshoe Drive
Williamsburg, Virginia 23185
(804) 229-2152 [After 6pm eastern time only]
Arpanet: rs4u@andrew.cmu.edu
Uucp: {your fave gateway}!seismo!andrew.cmu.edu!rs4u
Disclaimer? I don't even KNOW 'er!jlc@atux01.UUCP (J. Collymore) (05/19/87)
In article <gUg4szy00UhTxdA0VA@andrew.cmu.edu>, 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. Example: Where I work (no names, to > protect the innocent), there's a programmer who graduated > cum laude in Computer Science. 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! > > 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. > Until more managers (and individual programmers) finally realize that "Human Factors" is more than just a buzz-word, you will continue to see programs and systems designed in a manner that will usually fall short of being "user-friendly." When more programmers and project managers include Human Factors psychologists as integral parts of their projects, (and not just as "figure-heads" or "scape goats" whose input they neither acknowledge or implement); and when serious "user acceptance testing" as part of the overall system test plan is done, then we as consumers, may see software (and hardware) that really makes us feel we bought a GOOD computer product. Jim Collymore Disclaimer: The above opinions are nd get 8
hallett@othello.steinmetz (Hallett) (05/20/87)
In article <gUg4szy00UhTxdA0VA@andrew.cmu.edu> 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
kentb@apple.UUCP (05/20/87)
The notion that it is "human factors" that are needed to make programs "user-friendly" is a dangerous fallacy perpetrated by human factors "experts" in the interests of job security. The Mac gives us many examples of programs which follow the user interface guidelines to the letter but are horrible programs to actually use because not enough thought went into structuring the application in the first place. While it could be argued that the Mac UI guidelines are slightly less than the pinnacle of human factors thaey aren't too far short. What is really needed is more understanding of the problems the computer is being used to model, understanding that only the eventual users of a system (the people with the problem, remember them?) have. I was graphically reminded of this when I consulted on a project which the software engineers had nearly complexified into extinction. We went to the application engineers, the ones who knew about the problem the system was trying to solve, and had them design the interface. The software engineers had to implement the system, though, and nearly ruined it again. Put me down for one vote against "human factors" and one vote for "user factors". Kent Beck Apple Computer, Inc. 20525 Mariani, MS 27E Cupertino, CA 95014 uucp: kentb@apple.UUCP csnet: kentb@apple.csnet 408/973-6027 -- Kent Beck Apple Computer, Inc. 20525 Mariani, MS 27E Cupertino, CA 95014 uucp: kentb@apple.UUCP csnet: kentb@apple.csnet 408/973-6027
hallett@macbeth.steinmetz (Hallett) (05/21/87)
In article <797@apple.UUCP> kentb@apple.UUCP (Kent Beck) writes: > ... >graphically reminded of this when I consulted on a project which the >software engineers had nearly complexified into extinction. > > ... The software >engineers had to implement the system, though, and nearly ruined it again. I propose then that these "software engineers" were not competent ones. Software engineers shouldn't be tied to "human factors" so nonchalantly. I do not suffer from the delusion that human factors will cure the software crisis and help Mom make better apple pie. Human factors have their place along with everything else. When they are applied poorly, problems will arise (as with anything else) and sadly, that is what it seems you found. As a software engineer, my goal is to create a product that the user needs, wants and can be comfortable using. What the devil is an "application engineer"??? 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. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
briand@tekig4.TEK.COM (Brian Diehm) (05/22/87)
>The notion that it is "human factors" that are needed to make programs >"user-friendly" is a dangerous fallacy perpetrated by human factors "experts" >in the interests of job security. > >What is really needed is more understanding of the problems >the computer is being used to model, understanding that only the eventual >users of a system (the people with the problem, remember them?) have. I was >graphically reminded of this when I consulted on a project which the >software engineers had nearly complexified into extinction. We went to >the application engineers, the ones who knew about the problem the system >was trying to solve, and had them design the interface. The software >engineers had to implement the system, though, and nearly ruined it again. > >Put me down for one vote against "human factors" and one vote for "user >factors". I see you complain of "Human Factors 'experts'" and then give a perfect example of their necessity! If you read your own "what is needed..." statement again, you will realize that you have perfectly defined the job done by GOOD human factors people. The point of human factors research is to keep in mind the ultimate user. In the case of your example, the people who did the engineering lost sight of this because they were too close, so the application engineers served the function of human factors people. Remember, most engineers feel somewhat threatened by human factors people, because they raise the specter of "control" being taken elsewhere. Also, it seems that EVERYBODY considers himself a God-given expert on human factors for his own project. Yes, I'm grinding my own axe here. No, I am an engineer, not human factors person. Yes, I've watched a lot of engineers screw it up because of ego or whatever preventing them from accepting someone else's expertise. Consider carefully, what are your REAL qualifications for determining how your users do their work, or how they should do their work? It is tough to answer this question honestly, but it is definitely an issue of engineering ethics and professionalism. -- -Brian Diehm (SDA - Standard Disclaimers Apply) Tektronix, Inc. briand@tekig4.TEK.COM or {decvax,cae780,uw-beaver}!tektronix!tekig4!briand