Collaboration tools, testing tools, or both?

October 01, 2007
URL:http://www.drdobbs.com/tools/collaboration-goes-down-under-to-meet-te/202103964

With us today is Pete Moore, product manager for Clover 2 at Atlassian.

DDJ: Pete, Atlassian has historically been positioned as a provider of collaboration tools for distributed development. Yet Cenqua, an Australian tool developer recently acquired by Atlassian, builds testing tools -- Clover, Fisheye, and the like. How do these mesh?

PM: While Cenqua's tools are far more developer focused than Atlassian's, the only purely testing tool is Clover. A big part of FishEye's value is enabling discussions about source which is especially critical in distributed environments. Crucible is distributed peer code review, so again very much a collaboration tool.

Note that before the Cenqua acquisition, Atlassian had already started down the developer tool path with their CI server Bamboo. To give you a feel about how all the products are going to come together, here's a couple of examples of the very cool kind of things that are on the cards:

• A developer checks in.
• Bamboo automatically kicks off a build.
• Thanks to Clover 2, Bamboo only runs the tests that exercised the classes that were changed.
• The build breaks.
• Bamboo sends a notification to the author including a diff of the couple of lines that most likely broke the build.
• Bamboo can then create a Crucible code review for the commit that broke the build. Thanks to FishEye, it can include the author of the change, the tech lead(s) responsible for that source, and the last couple of developers that worked near that code.
• Finally it can add a comment to any Jira issues that the commit is related to. Any of these artifacts can be easily included in Confluence wiki pages.

Suffice to say, that we are flat out like a lizard drinking trying to get these linkages happening in an open way. We think that there are a lot of people out there that are fed up copying and pasting between webapps but don't want to commit to a one size fits all solution. They will soon be able to select the products that suit them safe in the knowledge that the Atlassian products will work well together as well as playing nice with third-party and home-grown offerings.

There is also a team here driving the integrations that is tasked with creating a fully integrated hosted offering. It is relatively early days, but I think it will blow the equivalent offerings out of the water.

DDJ: Other than possibly less expensive labor costs, what are the advantages of distributed development?

PM: When it comes to labor, forget the cost. It is about recruiting the best talent. In software, 100 average people will get whipped by 10 great ones every time. Restricting your hiring to people who can get to the 16th Street BART station really limits your pool. The best people are always in huge demand and are increasingly taking lifestyle decisions into account. Distributed development enables you to cast a global net.

I could wax lyrical for days about the misnomer that offshoring for cost reasons is usually a recipe for disaster but I'll spare you that rant ;)

Another huge win for teams that adopt distributed tools is visibility (which brings with it accountability and measurability). By not relying on the "hey bob ..." communication strategy, you capture information in forms that lend themselves to collaboration and distribution. The team knows what is going on and don't have the excuse, "nobody told me".

Visibility is a boon for the non-developer stakeholder. Being able to watch and comment on issues and just get a vague feel for progress can really help them to view the dev team as something other than a black hold that keeps saying no to their requests.

There are so many things ... but my favorite part of having people spread across the world is that you have to have a bloody good reason to have a big meeting. As we all know -- meetings are productivity enemy #1. ;)

Note that Atlassian has not been big on distributed teams (95 percent of staff are in San Francisco, Kuala Lumpur, and Sydney with the vast majority of developers in Sydney). Although they are pretty comfortable with working from home. On the other hand Cenqua had less than half the team attend the office on a daily basis.

DDJ: When examining successful and unsuccessful distributed projects, what makes the difference?

PM: Like any project it comes down to people. All the tools in the world aren't going to save a project run and/or executed by gooses, massively under resourced, or with unrealistic time frames. Contrary to popular belief, I think that it is harder for an under-performer to hide when working remotely than it is in an office environment.

Finally, if you split a project into two or three parts in different locations that run like three separate projects - you are screwed.

DDJ: Is there a Web site that readers can go to for more information on these topics?

PM: Yep, www.atlassian.com.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.