jimad@microsoft.UUCP (Jim ADCOCK) (04/10/90)
Here's a few more random thoughts on this subject: Rather than ask what money can be saved by having less than one screen per person, ask what money can be saved by having less than one person per screen. 1) At the R&D organizations I've been at something like 90% of the budget goes to paying people's salaries. 2) The next biggest chunk of money goes to pay for the building. 3) Probably the next biggest chunk of money goes to interdepartmental cross charges. IE more people costs. ... 10) Equipment costs are typically lost in the mud. But what do all the bean-counters try to economize on? -- The Parato 10 equipment costs. Rather than the Parato 1 people costs. Personally, I think two [hardware] screens per program developer is a good number [Yes, even if they *are* windowing evironments.] Currently, I have 5 screens, though two of those don't get used much. Most companies make it *way* too easy to keep hiring people. Hiring someone new should be the method of last resort. Rather, ask if faster or more equipment can do the job instead. Regards sharing computers: Here's a simplistic, but not totally unrealistic model of the costs involved: Given a person P and a computer C, if the C is busy P is idle. If P is busy C is idle. One or the other is doing useful work. How do we minimize costs? Assuming that C is cheap relative to P, by making the C be idle most of the time, waiting for P. Not by making P wait on C. The bean-counterism of trying to minimize equipment costs goes back to the times when computers were expensive and people were cheap. Old ideas die hard. Time sharing was a way to try to keep C busy by sharing C between multiple P's. Rather, today the cost effective thing to do is to try to keep P busy by sharing P between multiple C's. For program developers the most important criteria for the friendliness of a development system is the edit/compile/link/test turn-around time. The least productive situation I've been in is in end project bug fixing mode where multiple programmers, management, etc, are involved in deciding what is to be done to resolve. Then the edit/compile/link/test turn-around time is days or weeks. This was hell. The next worse situation I've been in is a minicomputer environment where a bean-counter made sure that the minis were "used efficiently" IE cpu busy 80% of a typical day, and system administrators running their own personal tasks at a higher priority than the programming grunts. Edit/compile/link/test turnaround times were about four hours. This was also hell. A not uncommon situation to be in is to use micros on medium sized development projects before you have to do final integration. Turn around times in the low minutes. This is livable. Ideally, one has an environment where turn-around times are in the low seconds. This is bliss. Ideally, one's computers are so fast one can think continuously without any interruption waiting for a machine. If you have to wait long enough you lose your train of thought. Sharing screens between people pretty much guarantees that turn-around times are going to be in the hours -- IE you're going to have to wait a few hours until the other person is willing to give up the screen. This sucks.