`

`

`

`Large software projects require many specialists, such
`as programmers, database administrators, quality assur(cid:173)
`ance personnel, testers, and technical writers. Implicitly,
`at-home workers need at least dedicated telephone lines
`and two-way fax and e-mail communication with cowork(cid:173)
`ers and clients.
`Additional issues involve dealing with performance
`appraisals, awards, and especially the delicate subject of
`employment termination. Right now, there are more ques(cid:173)
`tions than answers about home-office work.
`
`Normal programming-office arrangements
`As a management consultant, every year I visit 20 to 30
`companies in the US and abroad. The most frequently
`encountered programming office arrangements have S(cid:173)
`foot partitions separating
`
`• small one-person cubicles of about 48 square feet,
`• two-person cubicles of about 90 square feet, or
`• three-person cubicles of about 140 square feet.
`
`I also see open office arrangements of perhaps SO soft(cid:173)
`ware personnel in large rooms, with file cabinets, fax
`machines, and supplies located along the periphery.
`A common problem with these arrangements is a very
`short "mean time to interrupt." My informal observations
`in the US indicate that personnel in shared work spaces
`experience some kind of interruption every 10 minutes (an
`incoming/ outgoing phone call, a social visit, or a noise or
`comment from the surrounding cubicles that interrupts
`concentration) .
`Assume every worker receives a phone call or a visitor
`about once an hour. With five or six workers in close prox(cid:173)
`imity, the cumulative number of interruptions can reach
`significant levels very quickly. It does not have to be that
`way, of course, but it often is.
`Several years ago, I visited a Japanese software factory
`that had an open office arrangement. According to the
`managers and personnel queried, this situation caused no
`apparent reduction in productivity. After a few hours at
`this factory, I noticed an interesting phenomenon: In a
`room with about 80 software personnel, barely a sound
`could be heard.
`Several design and code reviews were taking place in
`separate areas set aside for this purpose, but from a dis(cid:173)
`tance of about 30 feet the voices were not even audible. As
`I was noting this, another visiting American came into the
`complex. We shouted greetings to each other from across
`the room and started talking while still more than SO feet
`apart.
`It suddenly occurred to me that we were making more
`noise than anything else in the entire building. In the US,
`it's not unusual to carry on rather loud conversations at a
`distance. Although there's no reason why we can't, we sim(cid:173)
`ply have not developed a group-cooperation culture that
`lets us work in close physical proximity without interrupt(cid:173)
`ing one another. Typical US programming offices are
`rather noisy places.
`Programming is an intense mental activity that requires
`some periods of quiet concentration without interruptions.
`That is why, in the US, software office space significantly
`impacts software productivity.
`
`Hot Topics
`
`Editor: Ronald D. Williams, University of Virginia, Thornton Hall/Electrical
`
`Engineering, Charlottesville, VA 22903; phone (804) 924-7960; fax (804) 924-
`
`8818; Internet, rdw@virginia .edu
`
`Videoconferencing
`on the Internet
`
`Ronald J. Vetter
`North Dakota State University
`
`V ideoconferences are becoming increasingly fre(cid:173)
`
`quent on the Internet and are generating much
`research interest. I Readily available software tools
`enable real-time audio and video channels as well as shared
`whiteboards that allow groups to collaborate on distrib(cid:173)
`uted group work more quickly and easily than ever (see
`sidebar on available tools) .
`The Internet infrastructure is beginning to support video(cid:173)
`conferencing applications in several ways. First, the emerg(cid:173)
`ing multicast backbone (or MBone) can efficiently send
`traffic from a single source over the network to multiple
`recipients. I At the same time, many workstations attached
`to the Internet are being equipped with video capture and
`sound cards to send and receive video and audio data
`streams. The price/ performance of these hardware devices
`has finally reached a level that makes wide-scale deploy(cid:173)
`ment possible, which is perhaps the most important factor
`in the recent growth of videoconferencing applications.
`The CU-SeeMe videoconferencing tool is also becoming
`very popular. 2 Because CU-SeeMe was designed to run on
`a Macintosh AV, which has built-in audio and video sup(cid:173)
`port, it is an inexpensive way to undertake videoconfer(cid:173)
`encing on the Internet. A CU-SeeMe reflector (that is, a
`Unix host running appropriate control software) is the
`multicasting point for CU-SeeMe participants in a single
`videoconferencing group, whereas MBone users use
`"mrouters" to support their multicast packets.
`One important problem that must be addressed is the
`optimal placement (on the Internet) of mrouters and/ or
`reflectors. That is, certain configurations of mrouters/ reflec(cid:173)
`tors will result in better utilization of network bandwidth
`than other placements. For example, a reflector for a local
`CU-SeeMe conference session should reside "electronically
`close" to the site with the majority of participants. When
`there are hundreds of potential users and many mrouters/
`reflectors, the problem becomes even more acute, and it is
`easy to set up configurations that waste bandwidth because
`traffic flows over inappropriate links.
`
`Problems experienced in the virtual classroom
`My work with a project to demonstrate an electronic or
`virtual classroom over the Internet using available video(cid:173)
`conferencing tools has revealed several additional prob(cid:173)
`lems. 3 Although the project was successful, existing
`
`January 1995
`
`-
`
`Facebook's Exhibit No. 1005
`Page 3
`
`

`

`

`

`

`

`