Software Design 2e - DIM

The first of these problems is at least partly aided by the increasing trend towardsmodular designs, an issue that will be examined at a later point. For the moment, it issufficient to note that this strategy does help with the problem of subdividing thedesign operations among a team, although it is still necessary to ensure a fair balanceof effort, where appropriate.Bringing the elements of a design together, along with the accompanying negotiations,is again a mix of technical and managerial issues. While a process of negotiationmay be right and necessary, it should not be allowed to reduce the integrity ofthe overall design.Some of the original research studying how programming (and hence designing) isperformed by teams was described in Gerald Weinberg’s classic book The Psychologyof Computer Programming (Weinberg, 1971). In this he observed the effects of differentforms of group organization, ranging from groups that worked as an ‘egoless’ setof peers (in which different members of the group might take the lead for specifictasks), to those that had a highly hierarchical form.The more hierarchical approach was at one time advocated by the exponents ofthe ‘chief programmer’ school (Baker, 1972; Brooks, 1975). Set in the design context,the chief programmer functions as a chief designer, acting in a highly centralized role,with the other members of the team performing functions that are solely intended tosupport his or her activity. The parallel usually drawn has been with the surgical team– which rather begs the question of the very different purpose of the latter. Membersof the team might have specialized roles themselves, such as librarian, administrator ordocumentation expert, and there is a back-up who acts as the technical deputy to thechief programmer.In practice, few design teams seem to act along such lines, perhaps because thereare few great designers who can take on the very exacting central role it demands.Researchers have also sought to understand and model the psychological factorsthat influence team behaviour in designing (Curtis et al., 1988; Curtis and Walz,1990). The factors discussed in these references include:41Designing with othersnnnthe size of a team (there seem to be pointers that a size of 10–12 members is probablyan upper limit for productive working);the large impact that may be exerted by a small subset of the members of the teamwho possess superior application domain knowledge;the influence of organizational issues within a company (and particularly the needto maintain a bridge between the developers and the customer).This last point raises an important issue in that:‘Designers needed operational scenarios of system use to understand the application’sbehaviour and its environment. Unfortunately, these scenarios were tooseldom passed from the customer to the developer. Customers often generatedmany such scenarios in determining their requirements, but did not record them andabstracted them out of the requirements document.’ (Curtis et al., 1988)This point is an interesting one, for it is relevant not only to the use of design teams,but addresses a much wider organizational issue in itself. (Figure 2.6 shows the full set