Decomposition:

ABSTRACT

Putting It All BackRebeccaE. Gtiter

Befl Labs, Lucent Teckolo~es263 Shmm Bodevm& 2F-309

Napefile, ~ 60566 USA

beti@esearckbe~-labs.comh@://\wwv.beH-labs.coti-befi

Together Again ‘ “

building sofivare from the Perspectiveof the coordinationDesign and development work have become increasinglyinteresting to CSCW researchers. This paper introduces anew perspective for extimg that work. decomposition.Decomposition focuses on the activities required tocoordinate the assembly of an artifacL Using examplesdrawn from a study of three software developmentorganizations, I show how decomposition is a form ofarticulation work I describe how that articulation workinfluences the product produce~ and how the product itseKinfluences the coordination required- I discuss theimplications of a decomposition view for CSCW research.

KeywordsSoftware design stidies, ticulation wor~ decomposition.

INTRODUCTIONh the last few years there has been an increasing interest indesign among CSCW researchers. First, design is theactivity bat studies of work intend to inform [23]. Asdiscussions about the relationship behveen studies of workand systems development continue, design wi~ remain afocus of attention within the community. Secon& designis a highly collaborative activi~. It provides a goodopportunity to study issues that are relevant to CSCWconcetns.

This paper follows the tradition of examiniig thecollaborative aspects of developing sotiare. Developmentwork includes design activities, because the process ofshaping software never ends during development.However, thii study differs from many other investigationsof development work to date, that have focused on workthat occurs in meetings [4, 18], or how individuals reflecton the problem [Za. It is *O different from the sma~erpool of studies of coding work the development of thesofivare i=elf [7]. Finally, it does not take the broaderperspective of those studies that examine the oveti projectorganization of development work [S, 12].

~ls paper takes a different perspective, one that looks atthe process from its conclusio% a reassembled artifact.Specifically, I examine the process of designing and

permixion to make di~tal or hard copies ofall m P~ of fis ~~orkforpersonal or cl=oom use is ~ted without fee protided that copiesare not made ordistributed for profit or cornmertial ad%mtageand thatcopiesbear this notice and the full titation on rhe first page. To copyotimisa to republish. to post on senrem or to redism%uteto fists,requires prior spetific permission and:or a f-CSC\V98 Scatie Washingon USACop]tight A~f 199S 1-5S1134094/9S/1 1.-$5.00

issues ~ creates when the prod;ct is put back together. Icall this process of reassembling the productdecomposition. ●

The paper begins with an examination of the process ofdecomposition, where the overall problem to be solved isdivided into components. The process of decomposition isthen defined. I discuss three different kinds ofdecomposition work, and the coordination they require afterdescribing the methods and sites where this work wasconducted. Finally, I outline the implications thisperspective has for CSCW research. Specifically,considering the construction of sotiare systems from thisperspective yields two important findings for the CSCWresearch community. First, it grounds articulation work inthe technical realities of assembling products. Second, itoffers insights into the character of intergroup andinterorganizational coordination.

DECOMPOSITION IMPLIES DECOMPOSITIONThat software development involves coordination work isnot a new observation. h 196S North Atlantic TreatyOrganization ~ATO) convened a meeting in Garmisch,Germany fiat drew researchers from industry and academia.At this meeting the name software engineering was pickedas the title for the emerging research disciplineinvestigating the complexities of software development[19]. Akeady, the topic of coordinating the developmentof sofivare was being discussed as one of their challenges.

Around the same time, Conway was writing an explanationof why this was the case [11]. Conway’s thesis —subsequently this has become known as Conway’s Law —was that the structure of the code mirrored the structure ofthe committee that had designed it.

By the mid-70’s, the coordination involved in softwaredevelopment work was becoming increasingly important toresearchers. Brooks observed that adding more people to asofivare development project does not make the processhappen quicker [3]. Specifically, he argued that thecoordination overhead of adding new people would slowdown the project.

Like Brooks, David Pamas also recognized the importance “of coordination in software development. Like Conway,Pamas recognized a relationship between the peopleworking on the software and the product built. Hisattention was focused on the process of modulardecomposition.

393,.

-.. —

.—.——- .. .- ---- .. . ...>.-. :.’..,. . .._.

hlodular decomposition is the process of dividing thesotivare problem into smaller tractable pieces to work on.Once those pieces have been defie~ rmd the relationshipsamong the components specifie~ the work of developmentcommences. f~at was not well understood were the criteriato guide the decomposition hsel~ Parnas recognized thathis process was not only a technical division of theproduc~ but a division of labor among individurds [21].Specifically, the smaller pieces typicrdly would be assignedto the different individuals on the projecL who wotid thenknow how their code fitted into the bigger softwareproblem being addressed

Parnas argued that the advantages of doing a good modulardecomposition of a sofivare problem were more thansimply technical they were ako managerird. Spec%c&y hefiought that good modular decomposition codd reduce thecommunication required among different developers bye~iinating some of their relationships with others.

Despite the widespread use of modular decomposition,recent studies of software developers suggest that they stilspend over 50°/0 of their time communicating with others[22]. Clearly, relationships exist among developers thatneed to be articulated There are at least three reasons whythese relations may exisL FirsL some relationships aredefined at decomposition time. Second, legacy codecomplicates the decomposition process. The initialdecomposition of new problems onto an existing base ofcode is anrdogous to retrofitting or extending an existinghouse rather than building a new residence- SomerelationsK~psmaybe maintained simply because it is easierin terms of putting new features on to the existing codebase. Thii& it is well known that requirements changeduring the development Gfe cycle, and so as features aredelete& added and modified, those relationships are dlsubject to change.

This last reason is particdarly si@cant when trying tounderstand how relationships in code affect coordination.Specifically, understanding the relationships amongdevelopers and the code that they produce in thedecomposition phase provides only a Mlted insight intothe socird relationships that evolve and disappear duringdevelopment. Instead, I chose the more unusualperspective of examining tiese relationships from theperspective of putting the system back together. I crdl thea~gregate of activities seen born this perspectivedecomposition. ~Is builds on the work of TeKoglu andWagner [29], who observe that the relations amongdevelopers play a critical role in how products areassembled. It dso follows in the spirit of Button andHarper 16] who ar=~e that studies of work should gobeyond theoretical and abstract notions of work, andexamined the fived work of those studied

Sotivare decomposition occurs whenever the pieces of codeare put together. Obviously the sofivare is recomposedonce to be released to the customer. However, the sofivarenezds to be recomposed many times before tha< for testingpurposes. Therefore, decomposition occurs far more timesthan the inhial decomposition, and it is because it happensover and over again, I cdl it decomposition. It includes

basic configuration management practices, releasemanagement work, and other integration work. Thedecomposition perspective focuses on the work that it takesto reassemble the product from its pieces. ,.It is at the point of decomposition when the relationshipsamong the different system components become critical.The technical relationships among modules are known asdependencies, and they can take a number of forms. Forexample, if module A passes a variable to module B, thenmodule B depends on A to give it that information.Another kind of dependency occurs if module A containsinformation that B needs in order to compile. Then Amust be compiled before B. One of the hardest kinds ofdependency to fmd is when module A generates a certainbehavior during program execution which module B needs ●

to fiction. This last case is known as a run-time ““dependency, and is hard to see because there maybe scantevidence oftils relationship in the written code itself.

Dependencies become interesting from a sociologicalperspective because of the potential division of laboramong the components. men two modules are owned bydifferent developers and share a dependency relationshipthen the individuals fmd themselves needing to maintainenough communication about the state of their work withthe other person. If the communication fails the result isofien that the modules will not work together — either atau or as intended. It is at the point of decomposition whendevelopers are focused on making their code work not onlywith other pieces they wrote, but with yet morecomponents written by others’ that these relationshipsbecome the acts by which software is recomposed. Thestrength of those relationships also becomes the ability ofthe developers to put all the pieces back together and makethem work. In other words it is at the point ofdecomposition when a dependency among modules must beunderstood by all the developers that own the piecesinvolved.

The next section introduces the sites and methods used inthis study. Then I describe three kinds of decompositionwork that I discovered formed a routine part ofdevelopment module, subsystems, and institutional.Throughout the discussion I want to draw attention to the :intimate link between the social and technical aspects of Idevelopment that the developers fmd themselves managing. IIt is more than just grappling with an organizational. ;context of design work but that social relationships areembedded into the software itsel~ and furthermore, can bedriven and dictated by the technology.

SITES AND METHODSI used two criteria for selecting sites for this study. First,and foremost I wanted the organization to be successful. Idefined success simply as the ability to produce workingsofivare and sell it to their customers. Second, they alsoneeded to be willing to host a researcher, sometimes forex~endedperiods of time.

Tool Corp. is the vendor of a configuration management(Cm tool. At the time they were finishing a new releaseof the product as well as an upgrade to an existing version.

394

— -—

,, .—— .-.,..

Both products contained code born prior systems. Duringmy time there Tool Corp. grew from 14 to 1S developersand their product consisted of 1 million ~es of code@OC). I spent three months on site and conducted over100 interviews there.

Computer Corp. is a large computer company that producesa real-time operating environment They employ 700developers who are distributed across a number of sites intie US and otier continents. Their product suite consistsof around 10 tifion LOC. I conducted 14 interviews withdevelopers and spent three days on site.

Flow Corp. is the vendor of a suite of office technologies.The company employs over 1000 people spread out acrossdifferent sites around the world. As a result of theirproduct diversity it is hard to estimate the size of their codebase. I conducted 6 interviews with one group working onone product witiin the suite.

Methods...A qualitative approach was used to gatier and analyze theda~ In particular I used grounded tieory, a method ofdeveloping substantive formal theories from qurditativedata [14]. Grounded theory CWSfor a continual interactionbehveen data gathering and anrdysis. As the researchergathers new data they analyze it to see how it extends,motlfies, or contradicts the existing theory beingconstructed. The result of grounded theory is anex~lanation of a set of practices.

Data were collected using observation and interviewingtechniques. At au three sites I conducted non-participantobservation, by watching people at work and maintainingdiaries. I rdso used pardcipant observation data gatheringstrategies at TOOICorp. and Computer Corp. Participantobservation involves working in the environment beingstudied. The researcher Ieams — by doing — about theparticipants’ work

Two interview protocols, unstructured and semi-structure~were employed at the three sites. Unstructured interviewshave little if any interview tide and present opportunitiesto gather information about the concerns of the participants.These were used expensively at the beginning of the studyof Tool Corp. and towards the end to ml in any gaps in thetheo~.

Semi-structured interviews make use of an interview guide.The guide consists of a number of questions to ask tieinterviewee. The contents of the guide changed over thecourse of the study as the theory develope~ however, I wascareful to revisit old questions every so often to insure thatthe answers remained consistent among ~erent developersand organizations.

Data analysis consists of three stages known as opencoding, axird coding, and selective coding. Open codingconsists of reducing raw data to categories tiat explain thebehaviors reported. A category is a classification drawnfrom the field notes that describes an event. Thesecategories have properties that can vary along dimensions.An example wotid be the category of pain, that caa vw onthe dimension of how intense the pain was. Axial coding

395

involves developing these categories further, finding theconditions that lead to their emergence, and theconsequences of their occurrence. Selective codinginvolves picking one category as the core category thatforms the center of the theory. The three coding steps takeindividual cases of action reported and generate a formaltheory that can be tested and revised in other settings. Thevalue added in this approach is distilling what the peoplein the setting know and presenting it in an organized way.

...and PracticeThe data were collected from the three sites using thetechniques described above. hitially my interests focused

●

on the coordination involved in the production of software.This led very naturally to the decomposition work.Specifically, I began examining configuration managementpractices in place.

Whid interviews and observations focused on the formalprocedures and tools that developers used to performconfiguration management activities. I have written aboutthese practices and tool support elsewhere [15, 16].However, the interviews soon broadened to encompassother activities described by developers: talking withpeople, the use of meetings, and diagrams. My interestsdso broadened to the sum of all the activities involved inreassembling sofivare, from configuration management tolarger integration efforts, and final release managementtechniques. This usually meant re-interviewing the initialparticipants in the study to fmd out whether they wereusing informal methods of coordinating work, and whetherthey were involved in integration and release managementwork. The advantage of qualitative interviewing is that itallows for this on-going revision of the study during thedata gathering period.

The process of generalizing about how developers managedependencies in their work involves making a shifi fromwhat Strauss calls substantive to formal theory [2S]. Thiswas accomplished in two ways. First, I used and refinedthe concepts generated at Tool Corp. in the organizations Isubsequently visited. The discoveries at Tool Corp. helpedto shape and refie the interviews and the observations thatI made in the other organizations. Second, in eachsubsequent organization I revisited a set of core questionsasked at the earfier organizations. This combination ofrefining parts of the interviews while holding otherquestions constant allowed me to extend the theory throughthe collection of new facts and data, while insuring thereliability of previous data collected. Thus, the process ofgeneralization consists not of counting instances ofoccurrence, but through systematic collection of data thatelaborates on the patterns of behavior found in multipleorganizations, both extending and refining previousunderstandings. Finally, I took the results of my fieldworkand presented them to some of the developers I hadinterviewed and asked them for comments.

MODULE DECOMPOSITIONThe division of labor in software development workusually means that small teams of developers — oftencollocated — work on related parts of the system. Within

I

-— —, ,.

-— .— --- .>.... - —. —. .. —__

large subsystems, tiis division is firther applied untilsmall groups have established responsibility for a smallcomponen~ Decomposition work at this level involvesassemb~mg modules into pieces of the subsystem. b thiisection I describe three Kids of decomposition workmerging, single modde overtime, and change sets.

MergingJfien two or more developers work on the same piece ofcode simultaneously it is known as ptilel developmentImen this happens the fwst stage of decompositioninvolves making a unified module out of the versions thatexist Tools exist that automatica~y merge codq however,in many cases the developers find that they need to gettogether with their collea=wes and manually merge theversions.

Tools ftil to support merging well as the complexi~ ofwhat has to be merged increases [15]. Most tools manageto merge versions automatically if the components do notdepend on each other in any way. For example, one personchanged the comments and another altered a figment of thecode in an unrelated part of the module. However, somechanges can not be handed automatically because theyinvolve unrave~ig and sorting out dependencies betweentie multiple versions of the module.

Some developers related their mer=tig difficulties with theprocess of decomposition itseti. As one developer put ic

Perhaps the module itself needs to be broken up ...usually tils set of functionality belongs to me, otherp20ple working on the project are working on adifi’erent tictiontihy in the same module, thereforethe modules doing too much.

The complexity of merging increases when the developershave simultaneously altered the same lines of code ordgorithrn to address different problems. There are nowtechnical dependencies among the different changes thatneed to be understood and combined to produce oneaggregated version of tie module. Consequently,developers have to fid everyone eke, discuss what changesthey each worked o% and how tiey altered the code. Theywork together to develop a shared understanding of rdl theversions, and determine the functionali~ of the mergedmodu~e. This activity often takes place as a joint mergingeffofi The developers sit around one terrninrd and selectthe ~mesthat shotid go into the final merged module.

P~lel development involves mtitiple developers workingon the same module at the same time- The developersdepend on the same module for the work that they need tobe done, and they end up depending on each other-Meratig is the resolution of the technical dependencies thatexist between tie versions of the module. It dso involvesmanaging the social dependency among the developersworking on that module.

Sngle Module Over TimeMerging focuses on the relations among multiple versionsof a module that coexist at the same point in time.Ano&er set of dependencies exists among versions of thesame module over time. At all the sites I noticed that

396

developers ofien examined the previous versions of amodule before making decisions about how to proceed.

Developers described this behavior as necessary as part ofthe process of designtig the best solution for their currentproblem. Previous versions of a module represent anevolution of implementation decisions and a set oftechnical constraints and opportunities for fiture work.One developer justified why he went back to previousversions of code as seeing:

why this particular change was made urn how itdoes or doesn’t affect this next set of changes or youunderstand why this person made this change andhatit considered this other problem and that sort ofthing.

The developer is clear about the technical implications ofchanging the module without considering what hashappened previously. However, he also identifies anotherperson, the individual who made those changes in the past.

Dependencies with code in the past involve individualswho previously worked on that code. These kinds ofrelationships can get very complicated in establishedorganizations. As the sofiare and organization growolder, more employees move among projects. Otherdevelopers leave the company, and new people arrive totake their place. Consequently, many developers becomeresponsible for code they did not originally design and theperson who did is not available to explain how it evolved.The new owners are left trying to understand the character ●

of the sofivare from the code itself. New developersdescribed situations where they needed to Ieam about whatproblems previous developers had been trying to fix and ‘the reasons behind the choice of solution.

Some configuration management tools provide informationthat forms a kind of organizational memory, givingdevelopers some clues about who changed code, and why.The more readily this information is available the morelikely developers are to use it in their work, becausewithout it tracking down documentation or other peoplewho remember the person and their development work is atime consuming and sometimes inconclusive activity.

JWen developers do choose to ignore the past they are notin any doubt of the potential problems that it could cause:

If you have to go through a lot of steps to figure outthe history and do comparisons and things like thatyou tend not do that. You know cause I don’t havetime to do this, 1’11just kind of blast ahead andcross my fingers and hope that I haven’t screwed up.

Historical dependencies arise because the approach tochanging the present version of a module may depend onhow a developer changed that module in the past. Thisbecomes challenging when the module has changedownership, and one developer needs to understand the workof another. men the previous developer can not becontacted, then the current developer depends oninformation stored inside tools, organizational repositoriesand people who remember that development time.

——— —-.— —.—

— —._ —- ——— ..-..,...-

Change SetsThe previous two cases have focused on relationships thatexist between versions of the same module. Anotherrelationship developers manage derives Corn the fact thattieir work involves changing the behavior of the system.One logical change — a request for a new, enhanced orcorrected feature — often results in more than one modtiebeing rdtered hiaking the Iogicrd change involves tigningall the physical changes to the components so that thedesired outcome is produced The modties involved in thelogical change are known as a change se~ They depend oneach other to produce the feature requested Furthermore,usually tie change set must be introduced into the systemwhen all the physical changes have been made otherwisemy system btid wi~ probably fad.

A consequence of change sets is that the developersresponsible for making the necessary alterations to theircode become involved in a relationship with the othersworking on tie same Iogicrd change. Synchronizing dl thealterations and putting tie updated versions of the changeset back into the main line development requirescoordination. At all the organizations I studiedcoordinating chmge sets was a combination of manual andautomated procedures.

Developers at all the sites had access to some systems+ften problem tracking ticifities — that supported someof this change set work The developers would usuallybegin by identi~ing who they were working with on thechange se~ which involved extrapolating back from thephysicrd change to the statement of the logical problem tobe fise~ Typically the systems provided some clues aboutwho was working on related parts of the problem

Then the developers would get together and discuss howthey were going to implement the change as a group.Finrdly, one person wotid take responsibility for trackinghow all the physical changes were progressing, with theview to informing the person responsible for the systembuild when that change set was ready to be compiled.

This sequence of events is managed more or less fomdlydepending on the she and span of the change to be made.A small change involving two or three developers from thesame team was usually handled informally with thedevelopers erg-g themselves. men a change spans anumbef of subsystems and involves more developers thensome levels of management may formally orchestrate theprocess to ensure that the work remains Jlgne&

Change sets begin with the dependencies among modtiesw they are simultaneously altered to meet new systemrequirements. The technical component of the dependencyinvolves ensuring that rdl the altered code fictionstogefier, produces the desired behavior, and works with therest of the system. At the same time, the individualsresponsible for the physical chan~es, and sometimes theirmnnagemen~ need to form and maintain relationships toensure that everyone’s eff%rtsare synchronized

SUBSYSTEM DECOMPOSITIONThe previous section described the coordination required tordign a few modties together. This section focuses on the

work necess~ to assemble collections of modules intoparts of the product — subsystems — and the entiresystem. This kind of decomposition work also involvesmodules of code, but because it involves increasingly moreparts of the system so the processes required by anorganization to coordinate and accomplish this workbecome increasingly formalized and complex. I begin byexaminhg the complexities of recomposing a subsystem:the build. Then I discuss managing multiple builds of asingle subsystem, and finally describe the processes behindassembling the entire system.

BuildGroups of developers working on a subsystem often wantto test their changes — before submitting them to anofficial test group — against a working version of thesubsystem. A build is process for pulling together all themodules and components that make up the subsystem. Thebuild gives developers something to test their next changesagains~ and provides them with feedback on the changesthat they made that are inside the build.

I have described the advantages of using a tool to automatethis process elsewhere [16]. Instead, I want to describehow the technical dependencies among the pieces of codeform social relationships that have to be maintained, invarying degrees, by the person responsible for the build.

●

This person is known as the build manager.

The three organizations varied considerably on theirautomated support for build management. Among theorganizations where there were manual procedures in placethe role of the build manager involved maintainingimportant relationships that allowed them to build thecode. Specifically, the butid manager needs to know aboutat least three things.

First, they must be aware of any change sets indevelopment. A person responsible for managing a changeset needs to coordinate with the build manager to let themknow when to put all the revisions of a module into thebuild. Second, the build manager also needs to knowabout any compile-time dependencies that exist amongpieces of code. Compile-time dependencies specifi thatone module must be processed before another because it

,“

provides information to the latter one. Third, they need tounderstand the dependencies that exist among thecomponents in the subsystem as they were defined atdecomposition and have evolved. By this I mean that theyneed to know how the subsystem produces its functionalityand what kinds of run-time dependencies exist among thecode within the system. This piece of informationbecomes particularly useful when the build breaks and theyneed to identify the source of the problem.

For these reasons build’ managers try to have closecommunications with all the members of the developmentteam. Depending on the degree of tool support for thebuild process, build managers interact with their colleaguesto find out what code the developers are working on, whatimpacts that has on the subsystem, and where thecomponents reside. The work of the build managerinvolves maintaining up to date information about all the

397

—. .—.——— .-— -::,-. —

tecti~crd dependencies in a subsystem; consequently, theyfind themselves sustaining relationships with everyoneinvolved in the development effofi

The degree of formtilzation of the build manager rolevaried among the three organizations. At Tool Corp. andin the part of Flow Corp. I studle~ the role of buildmanager was an additional responsibility on top of onedeveloper’s work The build managers at these sites wereresponsible for doing build work within fairly small teamsof developers. Computer Corp. was a much biggerorga~~on, ~d some of fie subsystems were big enough&at they had ml-time staff that wotid pefiom the buildfiction for their systems. Computer Corp. dso had someteams that were smrdl enough to provide their own buildtiction intemdly, in much the same way that Tool Corp.and F1OWcow. di~

Platforms Creating Multiple Ufe CyclesThe need to compete for market share creates anotherdependency. It is only applicable to those developmentefforts that span mtitiple hardwme and software platiorms.It is a dependency when code is shared and developed formtitiple platiorms sirntitaneously.

l~en the companies I studied made a decision to offertheir product on a new platform they did not double thedevelopment effofi Often parts of the code remain thesame across platforms and new platform-specific pieces arecreated in the development environment to accommodatethe differences. This approach means that the system nowdepends on the platform-specific components to provide thefunctionati~ of the product to the new platform. At dl thecompanies I studie~ some developers become responsiblefor working on the platform-specific pieces of code in thesystem.

Typically with anew development effoz some initial workneeds to be done before an~mg is ready to compfle. Onesolution the developers used was to copy a version of thesystem into fieir workspace and develop the variants fromthat As changes carried on to the main developmenteffo~ the copied code became increasingly mistilgned tothe main development effort. So, at some point the newplatform variants need to join the main development effortmd be re%lgnti

fie technical-dilemma ticed is that if they are introducedtoo early hen they are unstuble and under tested and as aconsequence likely to break the build. However, if thedevelopers wait too long the main system will havechanged so significandy that the build may break due tothe fict that the platform variant modules assume a set ofbehaviors that the system no longer produces. Onesolution developers used was to recopy the system to theirprivate workspace with increasing tiequency as theyapproached the point when they wanted to put theirplatform-specific changes into the central developmenteffo~ This prevented the gross misafi=-ent fromoccurring towards the latter stages of platform variantdevelopment

By reusing as much of the system as possible, thedevelopers created a dependency between their platfom

specific code and the rest of the modules. They had alsocreated an important relationship that they needed tomaintain, one that allowed them to time when their pieceswould go into the system. The relationships would need toprovide them with enough information to plan how toprepare to fit their work into the development effort. Thiscoordination requires working with people who are familiarwiti the current state of the system and can suggest whento put certain pieces back into the system.

Iwo these individuals happen to be is highly contingenton the specific arrangement of work within thedevelopment organization. I found that the developerssought out people who had detailed knowledge of thecurrent state of the system development. In some casesthat was the person responsible for managing theintegration of the code. k other cases, developers tied tomanagers for help finding out when introducing their codewould not do too much harm to others. The commonfeature here is that developers who create relationshipsbetween platfom-specific components and the main systemfid themselves needing to maintain strong ties to the restof development or risk mistiming the introduction of theirwork into the central effort.

Assembling the Entire SystemThe product also needs to be integrated as a whole, which ~involves making sure all the subsystems work together. AtTool Corp. assembling the entire system was equivalent to ●--assembling two groups’ work, as the organization wassmall. The coordination work involved in assembling thesystem was much greater for larger organizations such asComputer Corp.

At the sites studie~ systems assembly work consisted oftwo stages. Firs\ the individual teams needed to aligntheir work with other groups with whom they shareddependencies. Once that was done the entire system neededto be assembled. At the time of the study, neitherorganization had any tools that automated the entirefunction. Instead, the companies used a combination oftechnical and organizational solutions to making the ~product work as a whole.

Tool Corp. was able to align the two subsystems it had ~fairly easily. E~erts for each team were well known to all ~the developers there so they could check individual ,problems throughout development. The build managers for :each system also worked closely to maintain alignment. ,

Computer Corp. used two strategies to manage thealignment issues. Some pieces of the system are morecentral than others. Changes to those pieces of code hadimpacts across the organization because many subsystemsdepended on that code behaving a certain way. ComputerCorp. had established a repository and an organizationaldefined unit — the shared resources group — to manage ~the problems of commonly used code. The sharedresources group had the responsibility of maintaining thecode in a publicly accessible repository.

The shared resources group also standardized ways of ~accessing the common code. They categorized the code by ~what part of the system it came from, and then informed all ,

398

.-

———- .= . ,-. ~.. . —,----- _

the teams where the code could be found inside therepository. This process formalized the ways that otherteams accessed the code by removing the individualcommunication required and replacing it with a formalprocedure. It ako helped to prevent the problems of hatigmultiple versions of a single piece of common code beingused by different teams in their development work

However, not dl code was managed by the shared resources~~oup. h the absence of the shared resources group takingcare of their code, teams had to find out who was usingtheir code. One mechanism some developers used was tobroadcast information about their systems electronictiy, inthe hope that people who were dependent on their codewould reply. The weakness of this approach was that thedependency relationships were identified by the individtiswho owned each componenL lWen the developer whoowned the remote code left or moved on to a new projectthe connection was 10SL If the relationship spanned largesections of the organization the developer who needed toreestablish contact witi the other side of their dependencytvould ~iely not know anyone to ask.

Computer Corp. was in the process of implementingtechnology that would sit on top of the CM tools and storeversions of subsystems that other groups could access.Part of the tictionatity of the system was to depersonalizethe code, remove individua~s names horn the modties thatthey worked on, and replace it with the team name. h thiscase depersonalization was an effort to make thesubsystems more recognizable by assigning ownership at ahigher level of abstraction.

At Computer Corp. the actual act of systems assembIy washanded by another separate organizational unit responsiblefor releases. All the groups working on the product suitewotid hand over a copy of their code to the release group atfixed points in the development life cycle. The release-moup wodd then test to see whether the code from&%rent groups worked together as exTecte&

Assemb~mg the entire system is a coordination intensiveactivity. It is the time when dl the subsystems must workwith each other. This drives a complex set of relationshipsamong developers and other people responsible forelements of this process. The management of Wlsrelationship requires the construction and maintenance ofcomplex documented procedures, organizational units, andsome technologies.

lNSTITUTIONAL RECOMPOSITIONThe development environments I have described haveappeared relatively autonomous. Most of the dependenciesand relationships discussed so far have been created bydecisions taken withii companies. However, outsideinfluences dso create complex relationships that managers‘ad developers have to manage as part of their work btils section I will describe just one of those relationshipsbrought about by open systems.

Open SystemsThe dependencies created by platfoms I descriied earlierfocused on fitting development effoti in different stages ofbeing finished together. However, platforms and other

kinds of software create another set of dependencies thatforced all the companies I studied to create and maintainmore complex relationships with vendors of other hardwareand software products. All of the companies I studied,built products that needed to work with other systems andas a consequence found themselves managing theserelationships.

One way that other vendors influence the developmentstrategies followed by these companies is through theirown releases. For example when a company released a newversion of its operating system, Tool Corp. found itselfhaving to make important development decisions.Specifically, Tool Corp. had to decide whether enoughpotential and existing customers of their tool wouldupgrade to the new operating system and whether thatwarranted starting a new development effort to make theirown product compatible.

Sometimes the companies I studied wanted a tighterintegration between their products and those of othervendors. Then some code must be shared between twoindependent vendors. At Computer Corp. I founddevelopers that work with other companies’ code, and whofind themselves dependent on how those companies chooseto make their own system revisions.

I spoke to one developer who -was hired into theorganization particularly for his experiences with a sotiarepackage that Computer Corp. wanted to integrate with theirsoftware. His own development, the integration betweenthe fivo products, was routinely impacted by changes madeto the vendor code, as he explained

basically you have to take their base and compare itto what they’ve given you now and see thedifferences there and then you have the choice ofeither implementing it from their new code orputting their changes into your new code.

These vendors change their code, not only in terms offunctionality of individual modules, but at higher levels, inthe architecture of the overall produc~ over time. However,sotiare development organizations who depend on othervendors, pay a high price for that dependency. Thedevelopment organization must adjust their code every timea vendor’s code changes. Quite frequently, thedevelopment organizations need to ensure that they supportboth new and older versions of the vendor’s code, allowingcustomers the option of upgrading or not.

Developers who have code that depends on other vendors’systems find themselves spending time reworking theirown modules to accommodate new changes from othervendors. Sometimes the connections between vendors letdevelopers interact with their counterparts in the otherorganization; sometimes managers meet and negotiate forinformation about product changes. Critically, for thesedevelopers part of the job of making their code workdepends on maintaining enough of a connection to theother vendor.

●

399

I

—— .—. — . .— — _“- ..-”. ___

?MPLICATIONS FOR CSCW RESEARCHk the last three sections I have described specific instancesof the coordination work required to produce sofiare.S~dyinS tie coordination from the decompositionperspective has helped to iden~ the occasions that createcoordination work, and what work individuals andorg~~tions ha~,eto do. A1hou~ I have focused on thedecomposition work necessary to assemble softwaresystems tiom their parts, decomposition work occurs inother settings.

Studies that include hardware design suggest that tie s~eissues arise there [5, 20]. For example, in hls studies ofen=tieering design, Bucciarelfi notes that synthesis of theproduct even at early stages of design is not simple. It alsoseems probable that this kind of work exists in theassembly of other tiacts, such as large documents writtenby multiple participants. h their study of the ~, Harperand Sellen [17] observe that professionals working ondocuments spend time corroborating their sections withtheir colleagues to make sure that they fit together. k thissection, I examine what the decomposition perspective hasto offer for our understandings of coordination work andorganizationrd CSCW.

Decomposition as Articulation WorkDecomposition work is a specific form of the broaderconcept of articulation work. Articulation work is all thecoordination and negotiation necessary to get work done[27]. Decomposition work is tie coordination required toassemble artifacts from their parts. Sctildt and Bannon[25] have argued that artictiation work focuses on workpractices that reach beyond small group settings andprovides a use~ conceptual tool for broadening the scopeof CSCW. Decomposition work includes local workpractices, but must rdso span the entire organization, andeven brings different companies together.

~ls study has illuminated four features of this kind ofarticulation work. First dependencies among the pieces —in tils case system components — create a host of complexsocial relationships that need to be articulated andcoordinated over long periods of be- Ftiermore thestren=ti of these relationships fiuences the organizations’abifity to assemble its artifact k other words, if theserelations~lps can not be maintained then it is ~ely that theartifict will not fit together, as pieces will drifi away andbecome increasingly misdlgne~

Secon& these relationships change overtime as the productchanges its technicrd character and the org-tion changesits social makeup. fiowing what they were when theartifact was orig”m~y designed is not enough, because therequirements change, the people change, and so the productis transformed People need to revise their understandingsof where the artifact is headed continually in order tounderstand what it has become-

Thii& any existing artifacts — in this case code — createseven more comp~cations. It creates difficulties for theinhird decomposition effort in ways that potentkdly createmore dependencies among various pieces than desired Forexample, the choice not to create an entirely new and

separate product for each platform means that all newdevelopment must fit with all the existing work going on.

Foti, these dependencies are not entirely under thecontrol of the organization. If another organization — acompany, a federal agency, or regulatory body — makesrevisions that impact the organization’s work, theorg~tiation must realign their efforts again. In otherwords, the decomposition perspective situates theproduction of artifacts in a broader institutional context.

b summary, this study ties the coordination work requiredto produce objects to the artifact that is developed.Specifically, decomposition grounds one type ofarticulation work in the technical details of what isproduced. This study demonstrates the importance ofarticulation work, the variety of types that occursimultaneously during the production of an artifact, andclarifies the character that these relations take during theprocess.

Button and Sharrock [9] observe that a relationship existsbetween technology and an organization. h this case, it isa relationship between the technology underproduction andthe organization shaping it. Decomposition work providesa mechanism for understanding how coordinationMuences the outcome of any artifact produce~ and in turnhow that artifact directs the coordination required.Furthermore, it suggests that there is a three wayrelationship: among the artifact — whether it be atechnology or not — produced, the organization buildingit, and any technology introduced to facilitate thedevelopment process.

Organizational CSCWRecently, CSCW researchers have begun to exploreintergroup and interorganizational forms of coordination[2]. This study shows that many of the tectilcal solutionsthat suppoti decomposition work exist for small groupstrying to coordinate their development efforts locally. Theamount of technical support decreases when multiple teamsor organizations are involved. At the same time, and notunsurprisingly, the number of organizational “fixes”increases. The establishment of departments, steeringcommittees, and other policies, all step in to address thecoordination needs that their current technologies do not[10, 24].

This study has outlined some of the ways thatorganizations coordinate their development efforts.However, the relationship between the artifact andorganization that I have identified also offers opportunitiesfor examintig potential organizational and technologicalsolutions for organizational CSCW. In the rest of thissection I discuss two occasions when decompositionprovides insight into organizational CSCW issues.

Loosely Coupled Wo& and ArchitecturesOkon and Teasley [20] describe one organizational solutionto the challenges of aligning geographically distant designwork. The solution that two teams — one in the USA andthe other in France — took involved slowly uncouplingtheir work over time. hitia~y they had an architecture thatrequired them to work closely. As the project evolved it

400

—. ——- . .- ..— ,.,,,>— ., ...._

became easier to redivide the work in ways that reduced thecoordination required They cdl this kind of work looselycoupled

This study suggests that when work is redivided toaccommodate distance then a corresponding change in thearchitecture of the artifact built must also occur (whichOlson and Teasley suggest happened in their study). Workcan still proceed in a loosely coupled fmhion withoutchanging the architecture of tie ~ifact, but sefiousdifficulties will arise. Althou@ it may save time initially,allowing different groups to proceed more independently, iftiey have to reassemble their product and the dependencieshave gotten misrdi=me~ it wfll take longer, and requirereestablishing the lost connections, and forgotten context.

~ls suggests that the architecture constrains the abfi~ ofdevelopers to choose tight or loose couphg independentlyof the artitict So, the &ct itse~ can provide a source ofinformation about what kinds of work can be distant anduncouple~ and those which if loosely coupled createdecomposition problems. This information could be usedto determine opportunities for groupware, and othersettings where those same technologies would be lesshelpful. F~errnore, by comparing the architecture withchtis that identi~ whether work is loose or tightlycoupled we can find places where work has become looselycoordinated when it should not be. Finally, thedecomposition perspective provides insight into the specificactivities that developers will find hard if the work hasbeen loosely coupled while the architecture demands tightcoordination.

Organizational Ati~renessIn their stidy of design work Bellotti and BIy [1] describehow individuals watched and taked with their collea=~esas a way of mainta~mg enough awareness of what otherswere doing. ~Is study confirms that developem engage inthe same practices to mainti this Mormation about whattheir team mates are working on. h these activities,developers associate information about other softwarecomponents with the individuals building them.

hfuch of the awareness literature to date makes this tiebetween individuals and artifacts. The three types ofawareness mechanisms Do~sh ~d Bello~ [13] desc~beall connect information about work states with anindividual responsible- hforrnational awareness allowsindividuals to describe what they dld ad role restrictiveawareness lets other deduce what work has happened basedon the role of the individual. Their shared feedbackapproach provides awareness of others witim a cormnodyshared electronic workspace. Changes to an artifact areassociated with the individual that made them in W theseapproaches.

~Is study suggests that awareness at an organizational]evel is subtiy Merent Awareness — what people need tobe aware of — changes when organizations attempt toassemble artifacts that span many divisions of thecompany. b the organizations I studie~ people involvedin subsystems and systems decomposition work found itmore useti to have components associated with the team

that produced it. h fac~ developers at all of the companiesI studied often referred to subsystems by the name of theteam that built them. Ofien the subsystem name was theteam name (i.e., the kernel group built the kernel). Forsystems development this means providing ways toaggregate and display awareness information about teams.Furthermore, it raises questions about how to representabstractions of team activity. *The notion of awareness changes radically when companiescreate alliances with other vendors. Companies areinterested in making their products compatible, but notgiving away proprietary information. What it mems to beaware, to maintain enough context to align products,becomes the discussion of management meetings and thecontent of legal documents.

CONCLUSIONSThe predominant way of thinking about design anddevelopment work focuses on the work to break theproblem into smaller components. This view permeatesthe literature about design as well as the techniques fororgtig project activities. Systems assembly seems toplay a minor role in this view.

Reversing our thinking from decomposition todecomposition places systems assembly at the center of thedevelopment effort. For CSCW researchers it highlightshow critical and just how difficult individuals findmaintaining congruency among all the parts. Furthermore,it establishes a foundation for explaining exactly howcoordination work directly impacts the artifact produced,and in turn how that artifact affects the coordination workrequired. The decomposition perspective also situates thiscoordination in the local and global contexts of production.Finally, it offers some insights into technological andsocial solutions for organtitional CSCW. Decompositionprovides a new tool for CSCW researchers to explore thecoordination involved in the production of largecollaborative tiacts.

ACKNOWLEDGMENTS~ls study is a product of the collective wisdom of thosewho manage these dependencies in their daily work. MarkAckerman, Lisa Covi, Jonathan Grudin, Jim Herbsleb,John L. King, Tom Redden, and Larry Votta providedsupport and helped me to articulate these ideas. I thank thereviewers for their comments. None of this would havebeen possible without the financial support of theEngineetig and Science Research Council of the United

,,

~gdom.

REFERENCES1. Bellotti, V. and S. Bly. Walking Away from the

Desktop Compute~ Distributed Collaboration andMobility in a Product Design Team. h Proceedings of i,

ACM Conference on Computer Supported CooperattieWork CSCW 96 (Cambridge, MA, November 1996),

I

ACM Press, 209-218. !

2. Bowers, J., G. Button, and W. Sharrock. WorMow!

from Within and Without: Technology and :,Cooperative Work on the fit Industry Shopfloor. hProceedings of European Conference on Computer-

..—-— .—.

— —___

3.

4.

5.

6.

7.

s.

9.

10.

11.

12.

13.

14.

15.

16.

— -— —-—-— ——---- . .

●

Supported Cooperative Work ECSCW Y5 (Stockhohn,Sweden, September 1995), Kluwer AcademicPublishers, 51-66.

Brooks Jr., F. P. The Mythical Man-Month.Datamatio~ 20, 12 (1974), 44-52.

Bucciarelfi, L. L. An Ethnographic Perspective onEng~eefig Design. D~ign Studia. 9,3 (19SS), 159-

16S.

Bucciarelfi, L. L., Designing Engineers MT press,Cnmbridge, ha, 1994.

Button, G. and K Harper. The Relevance of ‘Work-tictice’ for Design. Computer Supported CooperativeWork- The Journal of Collaborative Computing. 4,4(1996), 263-2S0.

Button, G. and W. SharrocQ The Mundane Work ofWriting nnd Reading Computer hograms. h SituatedOrder: Studies in The Social Organisation of Talkmd Embodied Activities, P. ten Have and G. Psathas,Editors. 1992, The University Press of AmericaWashington D.C.

Button, G. and W. Sharrock Project Work Theorganisation of Collaborative Design andDevelopment in Software Engineering. ComputerSupported Cooperative Work: The Journal ofCollaboratfie Computing-5, 4 (1996), 369-3S6.

Button, G. and W. SharrocL The Production of Orderand the Order of Production. k Proceedings of FI~thEuropean Conference on Computer-SupportedCooperative Work ECSCW ’97 @ancaster, UK,September 1997), Muwer Academic Pubkhers, 1-16.

Carstensen, P. H. and C. Smensen. From the Social totie Systematic Mechanisms SUppOrdng coor~afigin Desi=~. Computer Supported Cooperattie Work:me Jourd of Collaborattie Computing. 5,4 (199@,3s7413.

Conway, hf. E. How Do Committees Invent?Datamatio~z 14,4 (196S), 2S-31.

Curtis, B., H Kramer, and N. Iscoe. A Field Study ofthe Software Desi=m Process for Large Systems.Communication of the ACM 31, 11 (19SS), 126S-12S7.

Dourish, P. and V. Bellotti. Awareness andCoordination in Shared Workspaces. h Proceeding ofACM Conference on Computer-Supported CooperativeWork CSCW ’92 (Toronto, Canad~ October 31 -November 4, 1992), ACM Press, 107-114.

Gl=er, B. G. and A. L. Strauss, The Discovery ofGrounded Theo~ Strategies for Qurdhative ResearchAldine de Gmyter, Hawthorne, N Y., 1967.

Grinter, R. E. Supporting Articulation Work UsingConfiguration hfanagement Systems. ComputerSupported Cooperative Work: The Journal ofCollaborative Computing. 5,4 (199@, 447465.

Grinter, R. E. Doing So&are Development:Occasions for Automation and Formafisation. b

402

17.

1s.

19.

20.

21.

22.

23.

24.

25.

26.

27.

2s.

29.

Proceedings of Fifth European Conference onComputer-Supported Cooperative Work ECSCW Y7@ancaster, ~ September 1997), Kluwer Academic~blishers, 173-1SS.

Harper, R. and A. Sellen. Collaborative Tools and thePracticalities of Professional Work at the htemationalMonetary Fund. k Proceedings of ACM Conferenceon Human Factors in Computing Systems CHI ’95@enver, CO, May 1995), ACM Press, 122-129.

Herbsleb, J. D., et al. Object-Oriented Analysis andDesign in Software Project Teams. Human-ComputerInteraction. 10,2-3 (1995), 249-292.

NATO Science Committee. Working Conference onSofWare Engineering. NATO Scientific AffairsDivision. 1969.

Olson, J. S. and S. Teasley. Groupware in the WildLessons Learned from a Year of Virtual Collocation. hProceedings of ACM Conference on ComputerSupported Cooperative Work CSCW 96 (Cambridge,MA, November 1996), ACM Press, 419-427.

Pamas, D. L. On the Criteria to be Used inDecomposing Systems into Modules.Communications of the ACM. 15, 12 (1972), 1053-105s.

Perry, D. E., N. A. Staudenmayer, and L. G. Votta.People, Organizations, and Process Improvement.IEEE So@are. 11,4 (1994), 3645.

Plowman, L., Y. Rogers, and M. Ramage. What AreWorkplace Studies For? In Proceedings of FourthEuropean Conference on Computer-SupportedCooperative Work ECSCW ’95 (Stockhohn, Sweden,September 1995), ~uwer Academic Publishers, 309-324.

Schmidt, K. Of Maps and Scripts: The Status ofFormal Constructs in Cooperative Work. InProceedings of International ACM SIGGROUPConference on Supporting Group Work GROUP Y7@hoen&, AZ, November 1997.), ACM Press, 13S-147.

Schmidt, K. and L. Bannon. Taking CSCWSeriously: Supporting Maculation Work. ComputerSupported Cooperative Work (CSC W): AnInternational Journal. I, 1-2 (1992), 7-40.

Sch6n, D. A., The Reflective Practitioner: HowProfessionals Think in Action Basic Books kc., NewYork NY, 19S3.

Strauss, A. Work and the Division of Labor. TheSociological Quarter@. 26,1 (19S5), 1-19.

Strauss, A., Qualitative Analysis for Social ScientistsCambridge Universi~ Press, New York N.Y., 19S7.

Tellioglu, H. and I. Wagner. Negotiating Boundaries:Configuration Management in Sotiare DevelopmentTeams. Computer Supported Cooperative Work: TheJournal of Collaborative Computing. 6, 4 (1997),251-274.