| New forum for Rational Edge readers |
|---|
| At the end of this article, you'll find a link to a new forum created specially for readers of The Rational Edge ezine. Get ready to add your thoughts about this article or other topics you've found in our pages. |
Software developers, and technologists in general, are always looking for the next big thing. Many of us try to be the pundit who predicts the next trend in our industry. This month I'll take a stab at predicting one of the areas that I think is becoming a key for successful software development -- collaborative development and the tools that support it.
What is collaboration and collaborative development?
Software developers work in teams. Most of us work in a small team of 5-10 others to build a complete software product or a component of a larger product. Some of us work on much larger project teams and some work on a smaller teams, but most work on the 5-10 person teams. 1
Before we look at why I think collaborative development is so important, I should be clear about what I mean by "collaborative development." Clearly, whenever we work with others, we collaborate as a team using various types of information. For very small teams, there are few communication paths. As the team grows, the number of communication paths grows significantly. But collaboration is more than just communication. Collaboration implies the interaction of different entities -- individuals and groups -- working toward a common goal. Collaborators help each other by sharing knowledge and artifacts that get them closer to attaining their goal.
When it comes to software projects, we collaborate in several ways. We share a process with members of our immediate team. We make other teams aware of how we work and enable their work styles to mesh with ours. We share code, designs, tests, and other artifacts produced by our development process.
Collaboration is synergistic. When we collaborate successfully we perform at a higher level than we might otherwise. When we optimize interpersonal and interteam interactions, we reduce the barriers to getting work accomplished. Much like an automobile, when the parts work together, the car performs better.
A brief history of the 21st century
Over the last decade, the business climate has changed from one that was primarily competitive to one that is much more collaborative. In the software industry, we build component-based systems and systems built upon services, such as Web services. These components and services are not created by a single, homogeneous team. They may be created by developers anywhere in the world, for different purposes. When we find one that we would like to use, we often need to collaborate with the creators of the component or service in order to understand it and adapt it to our needs. Many of the components are available from open source providers. In such cases we often hire the provider, or someone familiar with the software, to adapt it and integrate it into our system.
As Thomas Friedman describes it in his highly successful book, The World is Flat: A Brief History of the Twenty-first Century, the world has changed dramatically. Successful businesses are beginning to capitalize on collaboration between the resources that best provide the services they need, regardless of where they are in the world. With an increase in collaboration, new markets arise for tools to support that collaboration. Collaborative development will be a major factor in the software industry for years to come. Let's examine some of the ways things might change.
New development methods and practices
We're experiencing a period of intense activity in software development processes. In this column last month, I examined the Agile processes, but Agility isn't the only area where new methods are appearing. We're seeing new approaches to all facets of software development practice, including methods that are geared specifically toward collaborative development.
Over time, collaborative development processes will become separate entities with their own characteristics and practices. Today's Agile methods typically address teams that are able to meet face-to-face, since communicating face-to-face is one of the basic principles of Agile. 2 But there are many in the Agile community who are working on developing and extending processes that can address collaboration activities when the team members are not able to meet with each other regularly. I believe that effective solutions to the problem will not be strictly Agile.
More formal, defined processes are addressing the need for collaboration across geographical distances. For example, the Team Software Process, originally developed by Watts Humphrey, is addressing the problem. 3 TSP is based upon the Software Engineering Institute's Capability Maturity Model (CMM) and the Capability Maturity Model Integration (CMMI). These models are used in many large organizations to manage large projects effectively.
Collaborating over geographical and temporal distance has come to the attention of many luminaries in software process design. Ivar Jacobson has been working on ways to combine practices effectively. He has written about his current approach in Enough of Processes: Let's do Practices. 4 Clearly, different practices are necessary when dealing with distributed teams that must collaborate effectively. Grady Booch has addressed collaborative development several times. 5 Booch and Jacobson are well-known visionaries in software development and they, along with others, have recognized the importance of supporting distributed teams.
Where might the current practices change? One of the first focal points will be the ability to synchronize a distributed team's activities and artifacts. We can already see this supported in some of the collaborative development environments used today. Rational tools, such as ClearCase, ClearQuest, and RequisitePro, provide the ability for a team to share different types of assets. Some collaborative development communities, such as VA Software's SourceForge, create a collaborative environment for open source developers. VA Software has created a collaborative development process that provides some best practices for incorporating SourceForge into an organization's existing process, as well as a complete process for organizations that have no currently defined process. 6 However, these features are only available in the enterprise version of SourceForge, and not in the generally available community on SourceForge.net.
Collaborative development tools
Tools that support collaborative development is an area that is ripe for new, innovative ideas. If any of my WPI (Worcester Polytechnic Institute) students came to me and told me they were interested in building tools for software development, I would encourage them to look at collaborative development tools and how technology can address the needs of teams that are distributed geographically and temporally.
What makes collaborative development tools so interesting is that there are short-term opportunities as well as long-term ones. In the short term, we must adapt existing tools to allow them to support distributed collaboration. Many tools have some support for this in their ability to support multiple users. Requirements management tools, source code management, and version control software have had good support for multiple users for years. Version control software has been the main approach to sharing artifacts on a project that are created by tools that don't support multiple users well. We often store documents, plans, designs, and other artifacts in a team repository of some sort in order to make them available in a consistent way to others on our teams. The central repository allows controlled access to the materials for all team members, and it presents a consistent view of the project to everyone. Distributed repositories have become a reality, although they still lag significantly behind the deployment of central repositories.
Today, there are some tools that call themselves collaborative development environments (CDEs). SourceForge and CollabNet are two of the more popular ones. Collaborative development, as embodied in these tools today, means a central repository for teams to communicate and share artifacts, including code. Each of these environments employs a database for storing artifacts and some kind of version control tool -- usually CVS or Subversion -- for source code management. They have extensions that allow them to use external tools, like IBM Rational ClearCase and other tools, to create and manage the team's artifacts. IBM has a new development platform initiative, called Jazz, which was announced at the 2006 Rational Software Developer Conference and will be soon introduced, that will supposedly raise the level of collaboration support. It is based upon the Eclipse framework.
At WPI we have been using SourceForge Enterprise Edition for almost three years. We currently have almost 1,000 users and over 300 projects hosted on it. "Hosting" is a good word to use for the capabilities that current CDEs provide. They "host" the resources that a team creates and consumes by creating a workspace for each project. They also provide some additional features that help a team collaborate more effectively. Since I'm most familiar with SourceForge, I will share with you some of the additional features that it provides for distributed collaborative development. I'll refer to the different parts of the environment by their "tab" names, as shown in Figure 1, but I will not discuss the features in the order that they appear here.
Figure 1. SourceForge Enterprise project tabs
First, we have Discussions, which are threaded topics that one might find on blackboard systems or other Web sites that support a distributed community. Recently, SourceForge incorporated the Wiki capabilities, which my projects use more than the discussion forums. A wiki provides a much less structured information architecture, but it supports a richer discourse among team members by allowing the structure of a discussion to evolve rather than remain confined in a structure.
SourceForge supports managing team tasks and tracking defects and other artifacts. The Tasks tab of SourceForge lets a team create a structured record of work assignments. The implementation allows a hierarchy of tasks that can map to the team in various ways. Most of the views in SourceForge let you filter the information you see in them and select the number of items you see per page. Figure 2 shows tasks filtered so that you see only tasks that are not started. The filtering mechanism is quite primitive and will hopefully improve as the product evolves.
Figure 2. Filtering the task view
Click to enlarge
The Documents tab is a general-purpose storage area for project documents or any other type of file that the team might reference or produce. One nice feature supported for documents is the concept of a review. You can initiate a review of a document, select required and optional reviewers, notify them, and be notified when the review is complete. This may seem simple, but it is a process that is often taken for granted or done in an ad hoc manner. Other CDEs and collaborative tools, like Microsoft SharePoint, also provide this feature.
Instead of tracking defects as a specific type of artifact, SourceForge provides a general artifact tracker. Each project can design, use, and track any number of types of artifacts. We have found this to be an extremely flexible feature of SourceForge. It lets us design defect reports, user stories, and other artifacts that we want to use for our projects. The File Releases tab is an important one for projects that produce software. We are able to package our products, possibly multiple configurations for different platforms, label them, and make them accessible to our customers with this feature. For open source projects this is a great way to make it easy for people to obtain your software in a ready-to-use form. The important thing for any CDE is to provide security. SourceForge and other CDEs take this seriously and offer the project administrator several ways to customize user privileges and access rights. Without such features, the CDE would be useless to an organization that wants to manage its intellectual property.
Still, there's no silver bullet
It's nice to have a CDE to work with. But there are still several things that inhibit true collaboration on a team. I have encountered two big problems:
- Using different tools for different purposes forces me to switch contexts too often.
- Using different tools that have overlapping functionality creates confusion.
Let's examine each of these issues. Consider what happens if I'm working in my programming environment (IDE) and I need to see the latest API or UML diagram for a module I will be integrating with through some Web service. It's possible that the information I require is in the source code management system I'm using, which my IDE links to. If that's the case, I might need to check it out and hopefully find a view in my IDE that lets me view the artifact. Eclipse and other such IDEs have gone a long way towards supporting this. But what if the artifact I need is in some other type of repository, like the Documents tab in a SourceForge project? In that case I have to leave my IDE, find the document in SourceForge, download it to my machine and attempt to view it, and possibly the view will have to be done via a third tool. The ideal solution would be to find the document in SourceForge and open it all from within my IDE.
A more severe problem occurs when I have different tools with overlapping functionality. Here's what happened as I tried to expose my students to a variety of software development tools. All of my students use Eclipse and SourceForge. We also have some licenses for Rally, a Web-based project management workspace that supports Agile software development. I wanted to use all three products in my class. Eclipse is the IDE of choice at WPI, SourceForge has the features described above, but Rally has great support for requirements management and supports user story and use case specifications. Besides, having to switch context to access each of these products, with different login identities on SourceForge and Rally, we encountered a clash. Each of the three products has a different artifact called a task.
In Eclipse, a task is little more than a tag with a name and limited state that is attached to some element in the IDE. The element might be a section of code or a file. In SourceForge, the task is an item that defines work to be done by someone on the team. It has a pre-defined format that cannot be changed. Rally's concept of a task is quite similar to SourceForge's, but the schema for the task items is somewhat different. Obviously, we had to decide what to do. The Eclipse notion of a task was too limited for our use. We did want to use tasks to schedule work for team members. But, if we chose to keep tasks in SourceForge where many of our other resources were stored, we would not be able to take advantage of some of the links that the Rally tasks provided to user stories and other requirements. We could manually duplicate the tasks, but that seemed just silly. Eventually, in order to reduce the amount of startup effort, we ended up not using the Rally tool. This was unfortunate, because I think the students could have learned a lot from using Rally for our requirements specification.
Now, let's take this problem one step further. What if you are working on a project with distributed development teams, each one using a different set of tools? This is not so far-fetched, given how much outsourcing and collaboration between companies goes on today. Imagine that Team A uses Eclipse for its IDE and IBM Rational ClearQuest for defect tracking; Team B uses SourceForge and Eclipse; and Team C uses NetBeans for its IDE and Rally for project management and its project workspace. How do these three teams collaborate? They either have to agree on a single environment for all teams or spend a lot of effort duplicating artifacts and keeping the environments synchronized. Neither of these is an acceptable solution.
The future of collaborative development tools
This complex possibility points out a sweet spot for collaborative development tools. If we are going to collaborate on a global basis, we must be able to merge development cultures and tools. This will require extremely flexible environments that allow tools to work together effectively. It's pretty easy to accommodate individual preferences for tools like text editors; in fact, nothing really has to be done. But, when you are working on a code base that is partly stored in a ClearCase repository and partly in a Subversion repository, you need a tool that bridges the gap.
In order to do this, we need two things to happen:
- Individual tools must be open. By "open" I mean that they need to have a well-defined API that lets other tools integrate with and extend them. The tools don't have to be open source, but they do have to be open-interface.
- Collaboration tools must be built that can easily abstract the concepts needed by the distributed development teams and resolve conflicts and represent those concepts as artifacts in each team's environment.
Many of the tools I've talked about here satisfy the first condition. Eclipse and NetBeans are two IDEs that are both open source projects and have a published API for building extensions to them. 7 Similarly, SourceForge and Rally have APIs for integrating with them. The APIs vary considerably in quality, mainly due to the maturity of the product, but this will improve over time.
A harder problem is satisfying the second condition. We need tool that enables us to synchronize project artifacts, even though they are quite different. Once we solve these problems we're well on our way to improved collaborative development environments.
The prospects for adding to collaborative tools are fantastic. We will begin to see integrated communication technology linked into our IDEs. We'll see ways of annotating video and audio in order to make requirements more precise and easy to understand across cultures. This is going to be an exciting time.
There is something on the horizon that I'm particularly excited about. As I mentioned earlier, IBM has a new development platform initiative, called Jazz that is getting ready for release. Although I don't know a lot about it, I have read some of the early research papers from the IBM research labs in Cambridge, MA, that discuss some of the foundation principles of Jazz. There have been a couple of presentations about Jazz at recent Eclipse conferences. Although I haven't been able to attend these conferences, I do know that Jazz is built upon the Eclipse platform and provides an integrated set of tools to begin improving collaboration among teams. Building upon Eclipse addresses some of the issues I mentioned above. I can't wait to get Jazz and use it to see how our research group at WPI can work with it.
1 Grady Booch stated this at a Rational User Conference several years ago.
2 See http://www.agilemanifesto.org/principles.html.
3 See http://www.sei.cmu.edu/str/descriptions/psp_body.html. It says that "The TSP is being developed for a wider range of project applications, including large multi-teams, geographically distributed teams, and functional teams [McAndrews 00]."
4 You can read this two-part article in Dr. Dobb's Journal, April and May 2007 issues.
5 See http://www.alphaworks.ibm.com/contentnr/cdeintro?open, http://www.ddj.com/dept/architect/196900222, and his paper with Alan Brown, http://www.booch.com/architecture/blog/artifacts/CDE.pdf.
6 See http://www.vasoftware.com/sourceforge/process_controls.php.
7 I am not sure whether CollabNet has such an API, but I would be surprised if it doesn't.
Dear Reader: A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
Learn more about Rational Collaborative software development.
Gary Pollice is a professor of practice at Worcester Polytechnic Institute, in Worcester, MA. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational Software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a B.A. in mathematics and an M.S. in computer science.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
