|< Day Day Up >|| |
With the ubiquitous presence of the Internet, it’s become possible to develop software with a team even when the team members are distributed among diverse geographical locations. As I write this, I am located in rural Eastern Washington, where software developers are not precisely thick on the ground. But that’s not keeping me from working on several software projects as a team member. I’ve got partners in Georgia, Seattle, Southern California, Florida, and Israel, just to name a few places.
Assuming you can get a decently high-speed connection to the Internet, remote collaboration is easier than ever. In this section, I’ll review some of the tools available for distributed teamwork, with my thoughts on how to use them effectively.
Is there any reader of this book who’s not already using e-mail? I doubt it. The question is not whether you’re using e-mail but whether you’re using it efficiently. Here are a few tips:
Make sure you have some form of spam protection to cut down on junk mail in your inbox. The built-in junk mail filtering in Outlook 2003 is pretty good. If you’re using an older version of Outlook, I recommend a Bayesian filter such as SpamBayes (http://spambayes.sourceforge.net) or Spam Bully (www.spambully.com).
Save all e-mail related to your project. Use whatever filing capabilities your e-mail client offers to organize it. With hard drive space being extremely cheap these days, there’s no reason to discard e-mail that you may want to refer back to in the future.
Treat e-mail as a tool, not an interruption. There’s no reason to interrupt what you’re doing by reading each e-mail message as soon as it comes in. Set aside time each day to deal with e-mail messages in a batch. If you can’t avoid looking as soon as the little message icon flashes, consider not even launching your e-mail client until you’re ready to answer messages.
Don’t send copies of everything to everyone. You can always forward a message later if someone else needs to be brought in to a discussion. E-mail works best for focused exchanges. For open-ended exploration of a topic, consider a conference call or meeting instead. Alternatively, try a Microsoft Exchange public folder or a private news server, where participants can read a discussion without having it all show up in their inbox.
E-mail tends to be the first choice for many developers to use for communication within a team, and it works well for this purpose. But don’t let your collaboration stop with e-mail. There are lots of other ways to share information online, as you’ll learn in the rest of this section.
Instant messaging is, in my opinion, another excellent tool for keeping team members in touch with one another. Of course, not everyone feels this way. Usability expert Jakob Nielsen has gone so far as to call instant messaging “toxic” and to declare that it “destroys productivity.” I can only conclude that he and I have different approaches to dealing with instant messages, because for me, it’s a real productivity enhancer.
As with e-mail, I find the key to effective use of instant messaging is to not let it dominate your schedule. When a new instant message comes in, you’re not required to answer it immediately (though you may want to take a quick glance, just in case the subject is urgent). Instead, wait until you have a pause in your other work to deal with the message. If both parties take this approach, a single conversation can stretch out over hours or days, but that’s OK; you can always scroll back to remind yourself what’s gone before. One thing that I find helps take the sting of urgency out of instant messages is to run the instant messaging client on a secondary computer, rather than on the one where I’m actually writing software. That way, incoming messages don’t take the focus away from what I’m doing.
A big problem with instant messaging is the proliferation of instant messaging services. If at all possible, try to get everyone on a project to agree on the same service, whether that be Jabber, MSN Messenger, Yahoo! Instant Messenger, or what have you. Failing that, you might want to investigate a client that can connect to multiple services, such as Trillian (www.trillian.cc/).
I find that it also helps to have a permanent record of instant message conversations automatically saved to my hard drive where I can easily search it in the future. Some instant messaging software can do this automatically; Yahoo!’s messenger client is an example. In other cases, there is add-on software to do the job, such as Messenger Plus, which extends MSN Messenger. Messenger Plus is available from www.msgplus.net/. One word of caution on this particular piece of software: Always do a custom installation so you can decide whether to install the accompanying sponsor software.
The key to using instant messaging and e-mail effectively is to manage them, rather than letting them manage you.
In some cases, you might consider anchoring your entire project at an online workspace. The two leading contenders in this category are SourceForge and GotDotNet.
SourceForge (http://sourceforge.net/) is a free repository for open-source code and applications that hosts over 70,000 projects. Projects hosted on SourceForge have access to a variety of services:
A web-based administration tool to manage the entire project
Web hosting for project-related content
A suite of tools to manage bugs and feature requests
Web-based discussion forums
A file release system, including distributed high-speed download servers
Access to compile farm hosts running various open-source operating systems
MySQL database hosting
A dedicated Concurrent Versions System (CVS) repository for source code control
To host a project at SourceForge, you must first create a SourceForge user account, which is a straightforward process requiring little personal data (though you must supply your legal name). The project must be an open-source project, as defined by the Open Source Initiative (OSI) at http://opensource.org/docs/definition.php. Among other things, the project must be licensed for free redistribution, including source code under a license that the OSI finds acceptable. These requirements make SourceForge hosting an unacceptable choice for most commercial projects, unless you’re planning to make money only from ancillary services such as training and support.
I’ll discuss software licenses in Chapter 14, “ Protecting Your Intellectual Property.”
Figure 11.1 shows the SourceForge project home page for a typical project (in this case, the ndoc code documentation generator for .NET code). This is the public face of the project, and provides access to releases, news, mailing lists, bug reporting, the CVS repository, and so on.
Figure 11.1: A SourceForge project home page
Microsoft has also gotten into the online project hosting business, with the addition of GotDotNet Workspaces to its GotDotNet community site for .NET developers (www.gotdotnet.com/community/workspaces/). Being much newer than SourceForge (and appealing to a much smaller number of developers), GotDotNet Workspaces has many fewer projects— about 5000, as of this writing. Projects hosted on GotDotNet have access to these services:
Source code control that integrates with Visual Studio .NET
Tools to manage bugs and feature suggestions online
Web-based discussion feeds
Hosting for release downloads
RSS Feeds for project-specific news
As you can see, the services at GotDotNet are somewhat sketchier than those at SourceForge, but (especially on the source code control front) they’re more aimed at .NET developers. GotDotNet uses Microsoft Passport for authentication; as a result, you must have a Passport in order to participate in or download code from a workspace. The site supports both public and private workspaces. Although the default license is based on Microsoft’s own shared source license, there is no requirement to adhere to a particular licensing scheme to host your code at GotDotNet.
To create a workspace, you must first register your user account using Microsoft Passport. You can then work through the workspace-creation steps, which are simpler than those at SourceForge. After agreeing to the site’s use agreement, you must then submit the license agreement for your code, which is entirely under your control. The final step is to provide basic details about your project (name, description, language, and so on) and to specify whether you’d like a public or a private workspace. The process is completely automated; as soon as you submit the workspace details, it’s automatically created for you.
Figure 11.2 shows the GotDotNet Workspaces home page for the .Text blogging engine. Like SourceForge, GotDotNet provides access to all of its essential features via a web interface.
Figure 11.2: A GotDotNet Workspaces home page
Online workspaces are a good fit for projects that need to have their code and releases widely available to both developers and users. I must admit, though, that I don’t find them a good fit for my own projects. The trade-off for the easy web availability tends to be a somewhat anemic feature set. Yes, you can manage your source code and track bugs and releases through either GotDotNet or SourceForge. But I think you can do a better job with a few simple tools that will cost you less than a few hundred dollars. If you’re in a particularly resource-limited situation, an online workspace may let you get started with team development without a large investment. Even then, I’d suggest you plan for a future when you can move your project to more powerful tools.
There’s another factor that makes me hesitate to recommend an online workspace: You lose control of your code repository when you opt to host a project with one of these systems. While both the Open Source Developers Network (OSDN)—the parent of SourceForge—and Microsoft have said they plan to maintain these workspaces indefinitely, this is a fickle industry. If the business climate changes, you could suddenly find yourself about to lose your online project hosting. In the absolute worst case, you could lose your code without warning. Although that’s not a probable outcome, it’s not one that I care to risk at all.
Another interesting tool for collaboration is the wiki. A wiki is a website that’s written by its visitors; every page can be edited directly in the web browser by anyone who can view it. You might think this would lead to an avalanche of spam and pornography, but wikis keep track of the history of each page, and successful public wikis tend to breed a community of people dedicated to keeping things well organized. Two good examples are the original WikiWikiWeb at http://c2.com/cgi/wiki and the open-source Wikipedia encyclopedia at http://en.wikipedia.org/. Figure 11.3 shows a page from the original wiki. As you can see, the layout is plain but the editor does allow users to format the text and insert hyperlinks to other pages.
Figure 11.3: A page from a wiki
Wikis are a simple but powerful idea. Although the original software was written as a Perl script, the idea is simple and powerful enough that it’s been implemented dozens of times in various languages (there’s a page with links to many implementations at http://c2.com/cgi/wiki?WikiEngines). Here are some versions that play well with Microsoft software:
Open Wiki (http://openwiki.com/) IIS/ASP based; uses Access or SQL Server for storage.
FpWiki (http://www27.brinkster.com/bleuciel/fpwiki/) IIS/ASP/FrontPage based; uses Access for storage.
SushiWiki (http://sourceforge.net/projects/sushiwiki) C# code ASP.NET implementation; uses SQL Server, MSDE, or XML files for storage.
FlexWiki (http://www.flexwiki.com/) Implemented in C# and ASP.NET; uses the file system for storage.
DotWiki (http://hcorrea.no-ip.com/dotwiki/default.aspx?topic=DotWiki) Implemented in VB .NET and ASP.NET; uses SQL Server or MSDE for storage.
You can set any of these wiki versions up on an IIS server with a minimum of effort. Although the thought of tracking your project on publicly editable pages may give you pause, that’s easily remedied by using IIS’s security features to require a login with password to access any of the pages in the wiki folder.
Because they’re editable by anyone on the project team, wikis are well suited to project teams organized as a community of equals. Such a team can use a wiki as a central repository for everything from design documents, to notes on bugs, to future plans, to everyone’s pizza preferences for the celebratory party when the product ships. The only major drawback to this scheme is that there’s no easy way (at least in the wiki software I’m familiar with) to link the data with richer document-oriented applications such as Microsoft Word or Microsoft Excel.
Another option for collaboration is Microsoft Windows SharePoint Services 2.0, the latest release of the software formerly known as SharePoint Team Services. As an optional (but free) component of Windows 2003, SharePoint provides a rich collaborative layer that any application is free to use. If you’re running Windows 2003, you can download the installer for SharePoint from www.microsoft.com/windowsserver2003/technologies/sharepoint/default.mspx.
SharePoint is built on the twin foundations of Microsoft SQL Server (or MSDE), and ASP.NET. SharePoint is implemented largely as a set of web parts, which are ASP.NET controls that run on the server. Web parts can display lists or images, retrieve stock quotes or weather forecasts, and perform a host of other tasks. Web parts are grouped into web part pages, which can be built and modified in an HTML editor, FrontPage, or directly in the browser. A typical SharePoint site might have sections for announcements, events, news, and so on, all of which can be edited in the browser.
SharePoint 2.0 introduces “Meeting Workspaces” and “Document Workspaces.” These are SharePoint sites organized around particular tasks and accessed mainly through Office 2003 documents instead of websites. A Meeting Workspace lets you organize the documents and tasks surrounding a meeting, while a Document Workspace provides you with a document-centric collaboration model. Document workspaces run inside a task pane interface as a part of Word, Excel, or PowerPoint documents.
SharePoint is at its best for intranet scenarios; it’s not designed to function well in limited-bandwidth situations. If your work involves organizing and sharing many Microsoft Office documents, you may find it a useful tool.
Another interesting collaborative tool is Groove Workspace, available from http://groove.net/. Groove is a general platform for collaborative content of all sorts: files, messages, project plans, notes, instant messages, you name it. Because Groove provides a variety of public APIs, it’s extensible to include more tools. The plumbing behind Groove is fairly complex, but the result is simple: All members of a workspace get synchronized copies of the entire workspace on their local computers (synchronization is carried on as a background task over the Internet, and does not require everyone to be online at the same time). Figure 11.4 shows a Groove workspace that I used to organize article publishing for a newsletter; I’ve also successfully used it to coordinate several software projects.
Figure 11.4: Groove Workspace
Groove comes in several editions, including a free Preview Edition (limited to creating three workspaces) and several paid editions, including a $199 Project Edition with Microsoft Project synchronization and other project-management features. You can experiment with the Preview Edition to decide whether the Groove way of working appeals to you, and then upgrade easily to one of the other editions if you like it.
Among other features, Groove is well integrated with Microsoft applications, including Office (imagine collaborative real-time editing of Word documents), Outlook, and SharePoint. You can use a Groove workspace as an extension of a SharePoint website to make it easy to share intranet content with partners outside your company. The major drawbacks of Groove in practice are that it doesn’t have much market penetration (so you’ll have to convince potential partners to install a copy) and its nonstandard user interface seems to be very resource intensive (requiring a powerful computer for good performance).
Finally, I’d like to mention two collaborative tools that don’t fit in anywhere else: CodeWright and CodeReview.
CodeWright (www.codewright.com/) is a programmer’s text editor that’s now owned by Borland. In addition to many of the features that you’ll find in other programmer’s editors (such as a flexible macro language and Visual Studio .NET integration), CodeWright includes an innovative feature that I haven’t seen anywhere else: CodeMeeting. CodeMeeting acts as an instant messenger client embedded directly in the CodeWright interface, allowing you to chat over TCP/IP with any other CodeWright user. Even better, CodeMeeting enables collaborative editing for documents open in CodeWright. Either user can edit the document, and both users will see the changes. This opens up the possibility of doing long-distance pair programming, with two developers working on the same code, which is one of the practices recommended by Extreme Programming advocates. There’s a free evaluation version available for download; a full CodeWright license will cost you $299.
Another interesting product is Macadamian’s $39 CodeReview (www.macadamian.com/products/codereview/). CodeReview adds a toolbar that lets you manage the entire code review process without ever leaving Visual Studio .NET. You can send out a chunk of code for review, add comments and suggestions to code under review, and accept or reject suggestions with a single click. If your entire team uses this add-in, you get the benefit of many eyes without needing a separate code review process or a separate code review application.
|< Day Day Up >|| |