Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!spool.mu.edu!agate!riacs!pioneer.arc.nasa.gov!lamaster From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.benchmarks Subject: Re: How do maxed out users compare to users with think times Message-ID: <1991Jun13.180800.11147@riacs.edu> Date: 13 Jun 91 18:08:00 GMT References: <676640053.AA19240@flaccid> <4046@sixhub.UUCP> Sender: news@riacs.edu Reply-To: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Organization: RIACS, NASA Ames Research Center Lines: 43 Bill Davidson writes: This isn't my opinion, IBM did a very serious study of this issue back in the late 70's, and since neither humans nor seconds have changed much I bet it's still valid (and no I can't find it any more, we used it for sizing for a while). Yes. At least three three articles have been published in the IBM Systems Journal during the last ~20 years. One of the authors is Thadhani. I don't have the complete set of references, but the Thadhani article is: "Interactive User Productivity", IBM Systems Journal, vol. 20, Number Four, 1981, pp 407-428. Look also at Vol 18, #1, pp 143-163, and vol 13, No 1, pp 1-18. In addition, the work has been summarized and presented other places, and I saw a summary of it last spring by an IBMer. The conclusion is simple: Subsecond response time does matter. More or less, most of the work I have seen, including the IBM work, and other work, points to having keystroke echo less than 100 ms, and trivial response time (time to respond to a small command, like "ls" of less than 200 ms. This is the *total* response time, including network delay, so the host delay often must be even smaller. The other conclusion that IBM has come to is that productivity improvements are, for lack of a better term, "multiplicative". Fast response time, good CASE tools, and high quality, well-documented libraries can combine to provide MUCH improved productivity over any single improvement. Which is good: it means that we aren't wasting our time providing better tools to programmers. It really makes a big difference in cost, productivity, and schedules. -- Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-1056 #include