Experience using a network of workstations by PATRICK HALL, PHILPARRY

and HOWARD WILKINSON

D uring 1983 it was realised that the two Vax 750s and one Vax 730 at Cirrus Computers Ltd

needed upgrading. These were run- ning VMS for the development of software written in C. A first cycle of enhancement led to the procurement of a further Vax 750, coupled with a resolve to network the systems, and adopt Unix as the primary software development environment. The 730 was converted to bsd 4.2 Unix in the second quarter of 1984, and the third Vax 750 was installed in the third quarter to run bsd 4.2 Unix, with one of the other Vax 750s being switched to Unix shortly thereafter. Network- ing of the Vaxes was, however, very

Abstract: While upgrading its computer installation, a UK company decided to provide w~kstat~o~ f~ its software ~ve~~~t engineers. Despite several problems which lessened the benefits which could have been gained, this move was found to be worthwhile. The company believes that greater productivity gives it another ‘half’ engineer for every engineer using a workstation, although this gain is diluted by support costs.

Keywords: data processing, software techniques, computer networks, workstations.

The authors are with Cirrus Computers.

rudimentary since the three Unix Vaxes were all in different buildings. This was acceptable in the short term, as we were planning a move into a different purpose-built building.

However, this was still not enough processing power, and it was decided that a number of Sun workstations wouid be bought for the next upgrade to the software development environ- ment. These would be networked using Ethernet to one of the Vaxes.

We have now had the Suns for around nine months. We have just moved into a new building with all the Unix Vaxes and Suns on a single Ethernet, and have ordered more Suns for delivery towards the end of the year.

This paper sets out the experience that we have had. There have been significant benefits, mostly in terms of productivity. However, there have also been costs, some of which have been much more significant than we had expected.

In making these assessments we have tried to set out those benefits that arise from other sources, such as Unix.

Cirrus development environment

The hardware listed below serves the needs of some 50 engineers and ten

60 001 l-684X/85/09006~04$03.00 0 1985 Butterworth & Co (Publishers) Ltd. data processing

systems

managerial and support staff. The company relies heavily on its electro- nic systems for communications, both within the site in Fareham, and to

other parts of the company both in the UK and in the USA and Europe.

0ur current hardware configura- tion is shown in Figure 1, and consists

‘.

Vax 750 with 3#.5 Mbyte main

memory, two 456 Mbyte discs,

running VMS , two Vax 750s with 3.0 and 3.5 Mbyte main memory, and each with two 456 Mbyte discs, running .Unix bsd 4.2, Vax 730 with two Mbyte main memory, 120 Mbyte and 10 Mbyte

discs, running Unix bsd 4.2, six Sun 21120s each with two

Mbyte main memory and a 130 .‘Mbyte disc, running Sun’s Unix version 1.3, :six Sun 2/5Os each with two Mbyte

main memory, discless, sharing part of a 120 Mbyte disc for paging and file storage, special systems used for hardware design and other purposes: two ,4pollo 66Os, two IBM PCXTs, two ,4pple Lisas, some inhouse-deve-

loped 68010 processors, terminals connectable into the Vaxes through a masterswitch, around 40 VT 100s and six VT240s,

output devices, a variety of printers with a laser printer being negoti- ated, and a graph plotter.

The Suns have high-powered Motor- ola 68010-based processors, with a high resolution monochrome screen with multiwindowing. They are arranged in ‘clusters’ of one Sun 21120 and one or two discless Sun 2150s which share the Sun 21120’s disc for paging and file storage across the

ethernet.

Increased productivity

The measurement of productivity in the software engineering domain pre-

~0127 no 9 november 1985

sents a major problem: there is no obvious metric that one can use. No reliance can be placed on crude mea- sures like, say, the number of key depressions made or lines of code written within a given period of time, because the output of a software engineer is intimately involved with the creative process - is a Sunday

painter producing ‘more’ than a skilled artist because he employs more brush strokes or canvases?

However, it does seem reasonable

to assume that any craftsman, of whatever level of skill, will produce work of at least comparable quality faster when provided with better tools. We may then conjecture what factors should be taken into account

when judging whether a software engineering tool is ‘better’ and hence

lead to productivity gains.

Shifting gear

Clearly if the steps taken by a person towards an ultimate goal can be made larger, as in the wearing of seven- league boots, then the goal is achieved

more quickly - this is the usual factor that one looks to for producti- vity gains (e.g. in fourth-generation languages).

Conceptual Notepad

People have inherent limitations and preferences which need to be recog- nized. So, for example, a person cannot work effectively on too many independent streams of work at once, and that where independent streams are necessary, aids in picking up the work when a stream is switched could be very beneficial. Further, human memory is not infallible, so that when a complex piece of software requires the consistent choice of versions of a large number of different compo- nents, or the propagation of changes to many separate but dependent sites, human memory can fail and omissions or mistakes occur. Assistance from the computer could be very beneficial here.

Chore reduction

Not all activity directly contributes to the goals of the work, some activities must be viewed as chores, like record- ing management information in time-

sheets, or tidying one’s desk over- night for security or other purposes. Removal of chores can be beneficial, both for removing unnecessary work from the engineers, and for removing irritations which reduce effectiveness

elsewhere.

Delay reduction

In any programme of work, stages in the work must wait for contributions from other sources (e.g. from com-

pilations). Where the delay is long and predictable, other work can be scheduled, but where it is short (say less than a day) or unpredictable, then reducing the delay can prevent idle time or unnecessary context switching

for the individual.

Interest

A software engineering tool should be

interesting and stimulating to use. This factor should not be underesti- mated in connection with tasks invol- ving a high degree of creativity. Soft-

ware engineers (presumably) like computers and will welcome the opportunity to interface with an ad- vanced piece of hardware. This leads

directly on to the next factor.

Flexibility

Tools which can be tailored to the particular requirements of the user

are evidently going to be more con- genial for hi&her to use efficiently. Fault diagnosis is typically an idio-

syncratic process’.

Methodology

Considerable gains can be obtained by changing the approach taken to the development of software, for example through design methods like Jack- son2’3, or reviews4, or configuration

61

Vax 750.. . . .:. . . . .

VMS . . . . . . . . . . .

Sun 2/120 ~ - Vax 750 *. . *:’ ’ ’ *

bsd 4.2.. . . .: . . . rl

Sun 2/lk?O Sun 2150

Sun 2/:20 Sun 2150

I

Sun 2/120 Sun 2150

I

Sun 21120 Sun 2150

Vax 750 *‘** :’ bsd 4.2 . . . . . :.

I

Sun 2/:20 I ‘.. Special

Sun 2/50 I hardware

Sun 2/50, Vax i30 . . : * ’ * . - _ bsd 4.2... .:.. .

--- Ethernet . . . . . RS232

Figure 1. Hardware configuration at Cirrus Fareham, UK

While methods and gearing are the factors that one frequently thinks of in productivity improvements (as in the adoption of a higher-level lan-

guage), it is our experience that the other factors can be equally significant in assessing gains in productivity from the use of a workstation tool.

Benefits

The Suns were placed with those engineers most actively involved in developing critical software products. Previously, they had been developing software using a VT100 connected to a VAX 750 shared with perhaps as many as ten other engineers.

From the management perspective we have seen a better isolation of inde- pendent threads of work, though it is very difficult to assess the size of any benefit here.

abled them to maintain several threads of work active with very easy switching of context between them (just the movement of the

mouse). This avoids taxing the engineers memory for the neces- sary commands to change the con- text, and saves the time actually typing the commands. There is rapid and predictable response, reducing computer in-

tensive steps like compilation and system building (making, linking) from possibly hours to minutes.

The Sun workstations met many of the criteria outlined above and have been uniformly welcomed specifically for the following reasons:

l The multiple windows have en-

62

The adoption of full networking capability, forced by the acquisition of the workstations, has greatly im-

proved communications, from mess- age sending throughout the company,

to movement of files between Unix machines where previously magnetic tapes had to be used for transfer.

There must also have been some Hawthorn effect - acquiring the Suns showed we cared, have the

engineers responded by working

harder? An increase in the productivity of

the individual engineers having work- stations is beyond doubt, and the size of the benefit is variously judged, by the engineers themselves, to be be- tween two and five times on code maintenance and enhancement.

costs

Even if the judgements concerning

benefits above are correct, the overall benefit to the company has been a lot less due to the factors set out below.

Initial teething troubles

It took us several months to set up our network and transfer the various tools that had been established on the

Vaxes to the Suns. This was largely because we had to learn to handle networks, and because of the choice of Sun configuration with paging across the network.

Basic costs of networking

The capital outlay on workstations is only part of the total costs. Cables have to be laid, Ethernet boards bought for the Vaxes, more memory supplied for the Vaxes to support the network, and the new problems asso- ciated with networks confronted, some of which are covered separately below. Since many of the network services, like spooling and mailing, are concentrated on the Vaxes, they are in effect resident and require main memory of roughly 512 kbyte per network service.

Lack of communication between developers

While isolating developers has some

data processing

systems

benefit in preventing accidental inter- ference, development engineers nevertheless must be able to com- municate, share files and send mess- ages. If the workstation does not come with this supplied, the software must be acquired or built,. and then con- figured to the particular network.

Lack of network software libray and inconsistent builds

Sharing of files requires more than the ability to copy files across the net- work, duplication of files must be controlled, and changes managed and propagated consistently. This re- quires an integrated software library across the network. An integrated filestore goes part of the way, but must be such that all basic software (like compilers) is neutral about loca- tion of files: Newcastle connection and the Sun Network File Store are not enough. Extra software must be built unless the workstation vendor can provide it, as with Apollo.

rn~reased s~~stern management costs

Extra processors, even single-user workstations, require more support staff. The ratio could be as high as one per two workstations, unless some of the management processes like the distribution of updates across the network can be automated. As a facility this must be designed into the network at an early stage.

Vu lying ne~~rks

The choice of tools which can be used at all locations in the network e.g. a word processor available on both Suns with high resolution graphics and Vaxes with VTlOOs, can be very limited.

Further, for successful networking, the communication facilities in all members of the network must be kept in step. Different vendors may have very different development paths, as

vol27 no 9 november 1985

we have found with one vendor appa- rently tracking the Berkeley develop- ments of Unix, while another seems to be being enticed by the AT&T deve- lopments and System V.

We would also have liked our VMS system to be included at least at the level of mailing, and have found this problematic. The lesson is clear, lack of homogeneity must be avoided if at all possible, at least until network standards like 0S16 are firmly estab- lished.

Large and infrequent runs

These need pooled resources. On a shared mainframe this is easily accommodated, though perhaps at the costs of degraded service to other users for the period. How do you handle this on a network of work- stations? One cannot make all work- stations capable of handling the largest jobs. We have explored a compute server, a 68020 Sun with 16 Mbyte main memory, but in the end preferred to give several Suns 4 Mbyte extra each. We may well fall back on the Vaxes for the really large jobs, once we have acquired sufficient real memory on these.

Conciusions

Is the purchase of workstations for software development cost-effective? Our belief is yes, and our company has underwritten this belief through the recent order for further work- stations.

The expenditure on workstations relative to providing adequate central facilities is quite small - perhaps only one third as much again. For the small extra expenditure on equip- ment, we obtain an overall productiv- ity gain of 1.5 times say, which effectively gives us another half engin- eer. However, this gain is diluted by the extra support costs, so the net gain is one quarter of an engineer’s time.

Is it worth it? Definitely yes. We shall recover our investment within a year, and indeed would be justified in

spending considerably more, as the break even point is where the margin- al capital cost per engineer equals the total annual salary and overheads cost per engineer.

Would we do anything different if we were starting again? Yes, the failure of the Vax and Sun approach to tackle the full networking and configuration management problems would make us look very closely at the Apollo Domain system7, and search for others that might provide equiva- lent or better solutions. We would also consider other central service solutions based on multiple terminals per user and the use of sophisticated editors like emacs, which would reap much of the benefit while retaining the flexibility required for the occa- sional large job. u

References

Duncan, K D and Shepherd, A ‘A Simulator and Training Technique for Diagnosing Plant Failures from Control Panels’ Ergonomics Vol 18 (1975) Jackson, M A ~~.nciples of Pro~anl Design Academic Press (1975) Jackson, M System DeveLopment Prentice Hall (1983) Freedman, D P and Weinberg, G M Handbook of Walkthroughs, In- spections, and Technical Reviews Third Edition, Little Brown, Bos- ton, USA (1982) Buckle, J K Software Conjimration Manage~~t Macmillan (1982) Tanenbaum, A S ‘Network Proto- cols’ ACM Safe Vol 13 No 4 (Dee 198 1) pps 453-490 Leblang, D B and Chase, R P ‘Computer-Aided Software Engin- eering in a Distributed Workstation Environment’ ACM SigsoftiSigplan Software Engineering Symposium on Practical Software Development Environments ACM Sigsoft Sen Vol 9 No 3 (April 1984) pps 104-112

Cirrus Computers Ltd, Waterside Gardens, Fareham, Hams, UK.

63