Best Practices for Collaborative Web Development
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
"Make this awful thing stop!" ordered Mr. Teavee.
"Can't do that," said Mr. Wonka. "It won't stop till we get there. I only hope no one's using the other elevator at this moment."
"What other elevator?" screamed Mrs. Teavee.
"The one that goes the opposite way on the same track as this one," said Mr. Wonka.
"Holy mackerel!" cried Mr. Teavee. "You mean we might have a collision?"
"I've always been lucky so far," said Mr. Wonka.
—Roald Dahl, Charlie and the Chocolate
The WSE Paradigm
One of the hard-won lessons we have gained from helping development groups implement more robust systems and procedures is that building an effective collaboration environment rests on clear roles and responsibilities. And whereas software tools help to facilitate the process and to automate certain tasks, development is fundamentally a collaborative social process.
With that in mind, we're going to proceed on two fronts. On the one hand, we're going to introduce and define a particular style of organization of individual and shared work products, and also introduce with a set of basic collaboration operations. This organization forms the technical underpinning for a content-management system. Then we'll interpret the meaning of the various operations within a social context of collaboration.
These two views are no different from the ways that we interpret a corner stop sign. At the technical level of interpretation, a stop sign tells us to bring our vehicle to a complete halt, under the threat of a traffic ticket if we are caught in violation. At the social level of interpretation, there's a tacit agreement between drivers at an intersection that fewer accidents and injuries result if drivers agree to stop and look both ways before proceeding through. By analogy, the content-management system defines the "rules of the road," but ultimate success and satisfaction will derive from understanding the intent of the rules and following them wisely.
We call the collaboration approach the WSE paradigm, shorthand for "workarea/staging-area/edition paradigm." WSE relies on multiple work areas, a single staging area, and some editions (versions of the web property) to organize the flow and integration of changes from developers. (See Figure 1.) The previous article introduced the notion of a workarea, which is an independent copy of the web property that is used to add, remove, and modify assets. The use of multiple workareas fosters parallel development of many tasks. Multiple workareas have the desirable effect of increasing the rate at which projects complete by giving each developer a controlled work environment.
){kind=link}
Figure 1 The WSE paradigm uses workareas, staging areas, and editions to organize the flow of changes from development to production.
Eventually the new and modified assets need to be brought together. This blend occurs in a single staging area. The staging area is like a workarea because it, too, contains a copy of the web property. But it is different because it accepts changes from a workarea. The staging area changes through the incorporation of new, modified, and deleted assets. This file-level versioning operation captures a copy of the asset and records the submitter, the workarea, the submission time, and comments.
Collaboration Strategies
In a collaborative development environment, each developer works on a task in a workarea. Depending on the overlap between her work and the work of others, the developer must be vigilant for changes submitted by her colleagues as she submits changes to the staging area. (See Figure 3.) Four collaboration modes are depicted in the graph shown in Figure 2. The most effective integration the incoming flow of changes depends on the nature of the collaboration among colleagues.
){kind=link}
){kind=link}
The horizontal dimension in Figure 2 indicates whether assets are primarily new or whether changes are primarily to existing assets. On one hand, the changes being made by a developer can consist primarily of new assets. For example, a contributor can create new assets, such as a writing a press release or building a new section of a web site. On the other hand, changes might involve mostly modifications to existing assets. For example, someone might be assigned to modify elements on an index page or to add a question and answer to the frequently asked question page.
The vertical dimension in Figure 2 indicates whether one or many people are making changes to assets of the task at one time. For example, the frequently-asked-question page may not be actively changed, so that there's at most one person making a change at a given time. On the other hand, because the index page typically functions as a gateway into major sections of a web site, index pages tend to have people attempting to update the same page.
When we overlay these two dimensions on a graph, we get four quadrants; these describe the most effective strategies to moving changes efficiently to production. In quadrant I, because assets are primary new ones, and because the assets are relatively isolated and infrequently changed by others, there is little chance for collision. Focusing purely on rapid development is the best strategy.
Figure 2 The activity type and the number of concurrent modifiers determine the best development strategy.
In quadrant II, assets are primarily new, but the section of the web site has assets that are frequently changed by others. In this case, the best strategy is to develop rapidly but to be cognizant of the changes made by others. This could mean frequent updates, or developers receiving notification when changes occur in the staging area.
In quadrant III, changes are primarily made to existing assets, and the changes are relatively isolated. Because the likelihood of collision is low, the best strategy is to develop rapidly, with occasional updates or notification to stay apprised of impending collisions.
In quadrant IV, modifications occur in existing assets, and the likelihood of simultaneous edits on the same asset is frequent. In this situation, the challenges of carefully orchestrating the efforts of the development team are especially great.