Manage Learn to apply best practices and optimize your operations.

The right tools for a distributed software development team

Use these three must-have tools to get the most out of a distributed software development team, but keep developer personal preferences in mind.

Limiting your software development team to people working in the same building might be easier than stretching a team across the planet, but you can get a wider selection of talent if you hire people who are scattered across a country or even across the world.

Doing so, however, requires that you understand how to make the most of a dispersed team. The rules that follow apply even to a team that's local but scattered throughout a large building. With these tips, you can make a software development team effective, whether its members are remote or local.

The right development tools for the job

Source code control: Thanks to the open source movement, software development teams are naturally spread out across time zones. In turn, software development tools, including those for revision control systems, have evolved with a stronger emphasis on distributed teams. Older systems used tight file-locking methods, so if a programmer needed a file that somebody else had checked out, getting it often was just a matter of walking down the hall. Open source teams are scattered about, however, with little direct communication among members. Thus, today's tools -- in particular Git, Mercurial, Fossil and Bazaar -- are well-suited for distributed software development because they fully replicate repositories on each machine. This method is different from that of older tools in that it focuses, not on locking the files but on merging changes. This can take some time for programmers to get used to, but open source projects have demonstrated its effectiveness.

Build tools: In conjunction with source code control, you should investigate automated "build tools." With every team member checking code in and out, you'll need a server -- possibly a dedicated one -- that runs daily builds. Examples are Apache Ant and Maven. (There's a large list of build automation tools on Wikipedia.) Build servers typically are owned by the quality assurance team, so who will report problems back to the developers. And how do developers report problems? That's next.

Issue trackers: Whether they're distributed or not, software development teams need issue tracking software. There are hundreds of options here, and all have strong points. With a remote team, however, tracking software has to be accessible from the far reaches of the planet, and should be integrated with the source-code control software. You might want to opt for an issue tracker with a Web interface if you have workers in remote regions where a VPN or Remote Desktop Connection doesn't function as well because of distance or poor Internet service.

Social and communication problems of distributed teams

In addition to being able to use build tools effectively, distributed teams need to be able to communicate well. The obvious tools are instant messaging (IM) and Skype, and even the telephone. According to a study in MIT's Sloan Management Review, however, two problems that can develop among remote teams are distrust and a lack of cohesion in interpersonal relationships. How do you manage these?

When you're managing a diverse team, you're bound to encounter cultural differences. The study in the Sloan Management Review makes some recommendations. For instance, tools like Skype can get you only so far, so periodic face-to-face meetings are essential, and allow team members to get to know each other on a more personal level.

More on mobile app dev

Forward-looking CIOs need to focus on app dev skewed toward mobile

Crafting one isn't easy, but CIOs need a mobile application strategy

Outsourcing trends: Mobile business applications for a business edge

Further, in 2007, CBS Money Watch interviewed remote manager Dan Belmont, who pointed out the importance of the boss working "in the trenches" with other workers, and communicating in a variety of ways -- not just via the telephone, for example.

That interview stresses the importance of personal preferences. As a programmer myself, I know firsthand that I can be extremely effective when I'm allowed to work according to my own routine and habits. Programmers tend to be more introverted than other workers, and they prefer IM and email, as well as flexible hours. The open source community has demonstrated how this can work: Tools such as Git are not built just for distributed work but also for teams whose members aren't necessarily working at the same time.

The takeaway? Remote teams can be as effective as local-only teams -- or even more effective. The key is finding the right tools and factoring in cultural and personality issues.

Jeff Cogswell

About the author
Jeff Cogswell is a software engineer with more than 20 years of experience in Unix and Linux, Windows, ASP.NET Web development, PHP development, and various database technologies. He is the author of C++ All-in-One for Dummies and other books. Additionally, he does training, primarily for Web developers and programmers. For more information, visit his website.

Let us know what you think about the story; email

Next Steps

Event planner ousts piecemeal systems with low-code development tools

Dig Deeper on Enterprise application development, DevOps and software agility

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.