|
Distributed development, IDE extensibility, and social software are taking
us to a development process that is not only more productive, but also
an enjoyable social experience.
January 11, 2007
URL:http://www.drdobbs.com/architecture-and-design/social-software-development-environments/196900164
The authors are members of the IBM Research Collaborative User Experience Group. They can be contacted at www.research.ibm.com/cambridge.
Software development is a social activity. Projects involve a team or multiple teams coordinating to produce a finished product. Whether open source or proprietary, a software development project requires people to collaborate. Team members, who may be collocated or distributed around the globe, meet and communicate face-to-face, over the phone, or online. Programmers ask their peers to consult with them, in-person or via screen sharing, to help review code and solve problems.
Now is an important time for developers to consider tools that support the social activities of software development, thanks to three trends:
Development teams are continuing to become more and more distributed. At a local level, with the increasing availability of broadband connections, developers can opt to work at home on occasion, reserving office visits for face-to-face meetings. At a global level, different teams coordinating on the same project are being established in different geographies and time zones. Open-source projects, by their very nature, are distributed globally.
At the same time, the environment where programmers develop their software has evolved from command-line tools, to powerful graphical editors, to integrated development environments (IDEs). The modern IDE is similar to a desktop office suite, but instead of a collection of tools for developing documents (text, presentations, spreadsheets), the IDE has tools for editing, compiling, building, versioning, and testing software. Modern IDEs (Eclipse, Netbeans, IntelliJ, Visual Studio, and the like) are also highly extensible, with mechanisms that let anyone contribute plug-ins. As a result, communities of programmers have developed that offer a multitude of IDE add-ons.
In the past few years, there have also been advances in the development and adoption of "social software," which lets people rendezvous, connect, or collaborate through software tools and form online communities (en.wikipedia.org/wiki/Social_software). Examples of social software include traditional communication tools such as e-mail, newsgroups, and instant messaging, as well as emergent tools associated with the Web 2.0 wave of Internet services, such as blogs, wikis, and social bookmarking (see www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html and "Web 2.0: Stuck on a Name or Hooked on a Value?", by Tim O'Reilly, www.ddj.com/188700856). Regardless of whether Web 2.0 is an over-hyped trend, a clear byproduct is the increasing adoption of social software (for example, new community sites such as MySpace are turning in record subscriber numbers). Software developers are among the adopters of social software. For example, various open-source projects use wikis (for example, see Eclipse's wiki.eclipse.org, Apache's wiki.apache.org, and Mozilla's wiki.mozilla.org) and some set up chat rooms to support developers (Mozilla IRC channels at irc.mozilla.org, Linux IRC channels at www.linux.org/docs/irc.html), and even commercial software companies increasingly showcase public blogs (Microsoft at blogs.msdn.org and IBM's www.ibm.com/developerworks/blogs).
These trends toward distributed development, extensible IDEs, and social software will influence makers of development tools to consider how to better assist the social aspects of development: awareness of team members' work, communication, and coordination around shared resources. Given that most development tools reside in the IDE, we believe that the IDE can become a collaborative development environment by embedding a variety of social software features that help support distributed development teams. In this article, we reflect on our research into collaborative development environments, explaining how they help support the communication and coordination needs of development teams. We conclude by describing some emerging collaborative development environments and speculating about the future.
In 2002, we began to explore integrating collaboration into an application development environment. This effort, the Jazz Research Project (JRP), is a system we developed at IBM Research that focused on providing a set of collaborative features for the Eclipse IDE (www.eclipse.org). (JRP is related to, but not the same as, Jazz from IBM Rational.) The aim was to promote interaction and team-building among a small, core group of developers, while capturing the team's artifacts to provide a useful knowledgebase and context for communication. The system was modeled after an "open office" approach to software development, in which team members are situated close together at their workstations, with shared space available for holding meetings, sharing materials, and collaborating at whiteboards. One important advantage of such an environment is "team awareness": While they focus on their own tasks, team members have a peripheral sense of the activities, discussions, and work occurring around them. Another significant characteristic of the open office is easy communication: People ask questions or provide information to the whole team, or call colleagues over for consultation. We wanted to provide the benefits of this type of open development environment, even in situations where developers may be distributed around the world.
Our system extended the Eclipse Java development environment to emulate the collaborative features of an open office: increasing the user's awareness of people, resources, and activities, and encouraging team communication. To promote team awareness, we elevated developers to first-class standing in the IDE—as prominent as files, folders, and libraries. JRP supplied an instant-messaging-like "buddy bar" along the bottom of the IDE that provides peripheral awareness of one's teammates. Each team member is represented by an image and, at a glance, you can tell who is online and working in the JRP environment. Hovering over the images reveals further details about developers' activities; for instance, what files they are currently editing or debugging (see Figure 1). From the buddy bar, users can kick off a variety of interactions, including text chat, screen sharing (useful for pair programming, joint debugging, and code reviews), and voice-over-IP telephony. Communication can also be initiated from the work context itself, by selecting a block of code to discuss. Chats can be saved as annotations, accessible from markers in the margin next to the code they reference or as entries in a team-wide discussion forum; team members who come along later can read and contribute to the existing discussions.
In addition to team awareness, JRP also provided "resource awareness" by extending the Eclipse IDE's Package Explorer file viewer. Files and other resources in the viewer are decorated with colored icons, indicating what other developers are currently doing with local copies of the files; for instance, which files have been checked out of source control, which have been edited, and which have been checked back in, making one's local version obsolete (see Figure 2). Decorators are also used to signal that someone is modifying a file at a particular moment. Hovering over a resource reveals a tooltip with further details; for example, who changed the resource and when. Resource awareness is also provided through extensions to the code editor: Markers in the left margin of the code automatically pinpoint where team members have made modifications. The decorators and markers help developers maintain a peripheral awareness of the activities of their teammates, including where others are working in the codebase and what issues surround specific parts of the code. Whether developers are working in the same building or around the world, the team- and resource-awareness features introduced by the JRP can help team members coordinate their work and avoid conflicts and duplication of effort. Moreover, collaboration happens in a contextual way: Developers are not forced to leave their core work environment—the IDE—to launch collaborative tools; they can instead easily access them as integral extensions to the IDE.
While JRP provided techniques that support collaboration within a close-knit development team, such teams rarely work in isolation: A team of developers may need to coordinate with other programming teams, as well as other groups that may consist of project managers, requirements analysts, quality assurance engineers, project managers, architects, designers, writers, and other specialists. In 2005, as a follow-up to our JRP work, we built a research prototype system—ActivitySpaces—that addresses the need for collaboration not just within teams, but also across teams (Figure 3).
The concepts of spaces, people, artifacts, and tasks are central to ActivitySpaces. Figure 3 shows the interface of a user (Figure 3(a)) who is currently present in the "Orion" team space (an individual can be in only one space at a time). The "Artifacts View" (Figure 3(b)) presents a shared, hierarchical view of the artifact repository for the space. Members of the team space can create, delete, and modify artifacts; they view and edit artifacts in the viewer/editor pane (Figure 3(c)). The "Tasks View" (Figure 3(d)) presents a shared view of the team's hierarchical "to do" list, representing work the team has planned, started, or completed. Members can create, view, and edit tasks; for instance, assign them to someone, modify their status, or associate artifacts with them. The "Current Task View" (Figure 3(e)) gives users a way to switch among assigned tasks, making the related artifacts, subtasks, and discussions for that task easily available, as well as providing awareness to other team members of which task is being worked on. Discussions taking place in the team space are contextual; that is, they are anchored on the team's artifacts or tasks. Users can select an artifact or task, right-click, and begin a discussion about the item. All teammates see a discussion entry appear below the item (Figure 3(f)) and immediately know what the conversation is about; if interested, they can click on the item to join. The conversations are shared by the entire team and persist until explicitly deleted.
The ActivitySpaces system provides users with real-time awareness of what is happening in their current space, namely information about their teammates, artifacts, and tasks. Like JRP, the buddy bar (Figure 3(g)) depicts members of the current space and indicates their status (color if present in this space, grayscale if offline, and grayscale with a green person decorator if they are present in another space). Tooltips reveal information about the teammates' locations and current tasks (Figure 3(h)).
At a glance, the Artifacts View reveals valuable information about the team's shared artifacts. If someone else has created or modified an artifact, its text appears in bold type until the user views it. The ActivitySpaces system has a simple check-out/check-in model for modifying items; and if an artifact has been checked out, it appears with a small person decorator. Mousing over the item brings up a tooltip indicating who has checked out that item for modification. Similarly, a glance at the Tasks View reveals rich information about the team's tasks. All team members can see that a task is new or modified (bold type), that it's in progress (asterisk decorator), that it's been completed (checkbox decorator), or that it has been checked out for modification (person decorator). Mousing over the item produces a tooltip with further data—who created the task, who is assigned to it, who has checked it out. In both the Artifacts and Tasks views, discussion items are marked with a person decorator if someone is presently participating in the discussion. Mousing over the item brings up a tooltip listing the participants.
One of the problems with conventional team space systems is that it's not easy for a user to easily see the information in a space that is of particular importance or interest. The ActivitySpaces system makes inferences about what tasks and artifacts are significant to particular users. For instance, a task is important to a user if that person is assigned to work on it, and an artifact is important to the user if it has been associated with one of their assigned tasks. Artifacts and tasks that are of particular importance to a user are distinguished by blue type, rather than grey, to appear more salient. If an important artifact has been created (or an existing important artifact has been modified), it appears in bold blue type, becoming even more conspicuous. Thus, while every member of a space sees the same structure in the Artifacts and Task views, each sees a customized view in terms of color and typeface.
The ActivitySpaces system supports a user's membership in multiple teams by providing a "space bar" view (Figure 3(i)): The icon at the far left indicates one's current space, while the icons to the right represent the other spaces to which one belongs. The space bar provides real-time, personalized cross-space awareness. At a glance, the view gives the user real-time, personalized awareness of what is happening "right now" in one's other spaces, without even leaving the current space. Space icons appear in color if at least one member is present (otherwise, they appear in grayscale). Hovering over a space icon produces a tooltip with real-time information about what's going on in the space, such as how many members are present, what activities they're engaged in, what discussions are occurring, how many artifacts have been created or modified since the last visit (and how many of them are important to the user), how many tasks have been created or modified (and how many of them are relevant). Users may decide to visit some of the more active and relevant spaces. The space bar supports easy cross-space navigation; clicking on a space's icon takes the user to that space, and the buddy bar and other views are updated to reflect the new context. The ActivitySpaces system supports cross-space collaboration via channels, a publication-and-subscription mechanism that enables spaces to selectively share particular content with other spaces and allows selective contributions, changes, and discussions from other spaces, without fully opening up the entire team space to outsiders.
IBM Rational has begun to publicize a project called "Jazz." Rational's Jazz effort builds upon our early work on collaborative development environments with the aim of bringing the Eclipse IDE into a new era of social development environments. Jazz is a software lifecycle team collaboration platform designed to support the seamless integration of tasks and tools across all phases of the software lifecycle. One of the additional areas that Rational's Jazz project is exploring is the incorporation of customizable process guidance, where tools understand the development process and help team members to follow the process.
In addition to Jazz, there are many other projects based on turning IDEs into social development environments. The Eclipse Communications Framework (www.eclipse.org/ecf) provides an extensible infrastructure for incorporating various collaborative capabilities inside the Eclipse IDE. Also, a variety of third-party plug-ins that support collaboration in Eclipse can be found at EclipsePluginCentral.com. Besides Eclipse, other IDEs such as Netbeans, Microsoft Visual Studio Team System, and JetBrains' IntelliJ provide various add-ons that embed collaboration.
Our research and these emerging collaborative development environments all strongly assume that the natural habitat of the programmer is the IDE, and therefore, take the approach of embedding collaborative capabilities and "social software" tools smoothly into the context of the IDE. Looking forward, this assumption may no longer hold so strongly, and systems may explore several new directions.
One aspect to consider is the changing physical environment of programmers. Multiple monitors, voice-over-IP headsets, webcams, and work areas with projector displays have become more commonplace, thanks to the dropping prices of hardware and increases in bandwidth. Perhaps future development environments will take advantage of these physical system layouts. For example, the Lighthouse project at the University of California Irvine (www.isr.uci.edu/projects/lighthouse) is beginning to take a look at optimal layouts on multiple monitors to help developers code as well as stay informed of the emerging design of a project. Also, the BlueWall project at the University of Saskatchewan (www.cs.usask.ca/research/research_groups/selab/projects/index.html) is investigating the use of vast interactive display surfaces via multiple monitors and projectors to turn a room into a shared software development environment for a team.
Something else to consider is the next evolutionary step of the IDE. With its plug-in nature and ability to traverse code, the IDE is becoming more like a web browser. Aptana (www.aptana.com) turns the Eclipse IDE into a JavaScript-focused IDE and blends in web-like characteristics, such as synchronization of the help system with an online wiki and support for dynamically creating Eclipse user-interface contributions via JavaScript programming (instead of compiling a Java-based plug-in). EclipseMonkey (www.eclipse.org/dash) applies the ideas from GreaseMonkey (greasemonkey.mozdev.org) to script and alter the behavior of the IDE (instead of the Firefox browser).
In the future, perhaps the web browser will become the IDE, at least for some purposes. Web-based word processors such as Google's Writely (www.writely.com) are approaching the capabilities of their desktop siblings, so perhaps the IDE will not be far behind. Wheat (www.wheatfarm.org) is a language and environment specific to creating dynamic web sites and it uses a wiki as its programming environment. Workspace (www.blog.createworkspace.com) plans to become a web-based programming editor.
Another direction for exploration may involve adding other types of social software tools, besides awareness and messaging, to the software development context. For example, social bookmarking (also known as "tagging") has become popular, thanks to shared bookmark services such as del.icio.us, and shared photo services such as Flickr (www.flickr.com). New social bookmarking sites specific to code examples have begun to appear, such as Code Snippets (www.bigbold.com/snippets) and ByteMyCode (www.bytemycode.com). We are also beginning to apply the ideas from social bookmarking to software navigation within the IDE with TagSEA, which is a joint project between the University of Victoria and IBM (tagsea.sourceforge.net).
There is great promise and potential in exploring tool support for the social aspects of software development. The research community and software industry have begun to discuss how to collaborate and move forward (for example, the CSCW 2006 Workshop for Supporting the Social Side of Large-Scale Software Development, lizzy.iit.nrc.ca/social_se200). With distributed development, IDE extensibility, and social software now accepted and widespread, we believe the development community can discover new innovations that will make software development not only more productive, but also an enjoyable social experience.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.