Although some problems are inevitable, there are ways to be more productive in your software development if you are prepared to take a risk and try some new methods.
Someone who has never shied from change is Tillmann Bruckhaus, who is an old hand when it comes to alternative software development practices. In 1999, when he worked as a chief architect at Sun Microsystems, Bruckhaus was using distributed teams consisting of people located outside the company to help meet development project constraints.
Today, he does the same thing at Numetrics, where he works as director of analytics helping to build software that uses business intelligence techniques to monitor the performance of development teams for integrated circuits software and firmware.
"We are working with remote teams. We have a team in Pakistan and they do the database and web programming, while an Armenian team brings the statistical and data mining expertise," says Bruckhaus.
Project managers taking this approach should be wary of their intellectual property leaking into the public domain, warns Struan Robertson, technology lawyer at Pinsent Masons.
"A popular misconception is that you own the code that the freelancer develops, and that is not the case. The freelancer owns the copyright to the code unless you specify otherwise," he says.
One of the biggest challenges for an executive trying to farm out elements of a project in this way is managing the developers.
"You must make the time for the additional co-ordination and communication. It may be difficult to judge the skill of the remote team, and you may, therefore, have less confidence in the project's schedule," says Bruckhaus.
Jack Repenning, chief technology officer at Collabnet, a collaborative platform for software development, agrees. Repenning, who has participated in open source software development projects since the early 1980s, says that for all the technological advancements that have been made, there are still significant difficulties facing project managers who employ staff in diverse locations.
"When you get into a situation where one person goes to bed before another comes to work, it can all fall apart, and I do not think anybody has managed that, other than by using scrum," he says.
Scrum is an agile development methodology in which a problem is divided into a set of discrete tasks assigned to groups. Its name alludes to the scrum formation in rugby where, as in scrum development, people fulfilling distinct tasks come together to form an effective whole.
Scrum emphasises short meetings designed to address immediate problems and keep tabs on progress on a frequent basis.
Repenning posits the "scrum of scrums" idea, in which a scrum dealing with a set of related tasks forms part of a larger set of scrums.
"There is one person called a scrum master in each team who keeps track of the status. The scrum masters will also meet, a little less often, and they deal with larger components of the task.
"The key point is that scrum masters do not have to be as tightly co-located," says Repenning.
Agile development practices, such as scrum, can be useful in dealing with the inevitable management overhead that besets projects with distributed teams.
"The key is that you must ensure the development is very transparent," says Kent Beck, developer of the extreme programming methodology.
Bruckhaus says, "If someone offers to do something for you as part of a larger development, then sitting back and waiting for the deadline day and expecting it to be met is a recipe for disaster.
"That is why agile development can be helpful in this context. You can work in small time boxes, so you can get a verifiable functionality back at a faster rate."
Tips to help accomplish this include daily code drops in which iterations of code are submitted on a frequent basis to a shared server.
They can then be reviewed by project managers so that any misunderstandings or potential problem areas are taken care of before they become damaging.
Automated tests to verify the code quickly and regularly, without bogging down development staff, are also crucial in distributed collaborative development scenarios.
When it comes to specifying projects from the outset, it is worth remembering the mantra "a stitch in time saves nine". This is especially important when dealing with people from different cultural backgrounds whom you are not seeing on a face-to-face basis each day. Ensuring that they understand the scope and requirements of the project from the start is crucial.
Sourcing the team members
Like many project managers sourcing members of a virtual team, Bruckhaus focused on people that he knew. He had a network of people who had previously worked for the company, but had subsequently emigrated. He was able to build virtual teams using these individuals as local hubs for talent.
Other project managers propose a more open method for building distributed groups.
Kevin Wade, founder of IT recruitment firm Topcoders.com, sourced design and development talent from people that he had never met, via the internet. "I have built 40 or so websites with freelance designers and coders," he says.
Wade used web-based hiring sites to find the skills that he wanted, before starting Topcoders.com specifically for software recruitment.
The site is due to be relaunched in about four months with new functionality, including tracking and extra administrative features.
There are rival sites doing similar things, such as Rentacoder.com. This site, which serves as a marketplace to connect buyers with coders, does not charge a finder's fee to the buyer, but instead charges the developer a commission for a successful bid. As with Topcoders .com, the payment for the job is held in escrow (by a third party) until the code is delivered and the buyer is satisfied.
Scriptlance.com, another site offering a similar service for web masters wanting to commission script programmers, charges a commission both to the programmer and the commissioning project manager, but the percentages are lower - 5% of the bid to the programmer, and a flat £2.50 fee to the buyer.
Tapping in to open source
Another way to find talent online is to tap into the open source market.
Many people who think of open source think of Linux, which has an extensive hierarchical network of developers who contribute code to the person directly above them in the chain. However, many open source projects have far fewer people (normally in single figures), which makes such complex management practices less necessary.
There are tools to help find open source projects and the coders who contribute to them, and they can also be used to find code that has already been developed by the open source community.
Sourceforce, a well-known orientation point for the management of open source projects, is one such point of call, but if you want to gauge the health of a project, consider a search engine like Krugle, which was built especially for developers, says Repenning, who was involved in a project for Collabnet to create an open source framework for distributed project management.
The Krugle service makes it possible to search for code, or for the projects themselves. Search results detail metrics such as the numbers of lines of code and the number of files in the project.
However, there are some potential pitfalls with open source projects. First, open source developers will be even less controllable than virtual teams.
"You need to remember that you are deriving your energy from this open source dynamic," says Repenning, adding that waving cash at them will not work.
"To some extent, no software developers anywhere are coin-operated, but open source developers in particular are not. They want to do the right thing, their own thing, and you have to respect that," he says.
For many people, the main rewards for working on open source projects are intellectual stimulation and recognition for their work. Consequently, managers have to understand the value of public praise, says Repenning. Understanding how to build a community around the project is crucial. That community needs to thrive on conversations that may well be sparked off by the project manager.
The other danger for companies using collaborative open source efforts lies with intellectual property. The traditional GNU General Public Licence (GNU GPL) dictates that any product using code developed by the open source community must itself be given to that community. In this way, it infects everything it touches with the open source "copyleft" ethos.
Make open source work for you
Fortunately, there are alternatives. The GNU Lesser General Public Licence GPL (LGPL) makes it possible for proprietary code and open source scope to co-exist. The BSD licence does not include the same infection clauses either, and the Mozilla public licence is also liberal when it comes to the commercial use of code.
This means that it is legally possible to combine open source developments with proprietary code (useful if, for example, there are certain parts of your intellectual property that you do not want to make public).
However, project managers should be wary of getting code that they had not bargained for. Proprietary code could make its way into code contributed by the open source community, or by paid remote workers, leading to a lawsuits further down the line.
There are ways to protect a company against such dangers. If using a paid contractor, then put some form of liability clause into the contract, so that the coder pays in the event of a lawsuit. Of course, it becomes important to ensure that they have indemnity insurance and will be able to pay the bills.
Technology can also help here, says Repenning. Products from companies such as Black Duck Software can scan your code and match against a knowledge base of publicly known code, to help inform you of any copyright infringements.
But all of these measures may not help project managers caught in the headlights, after all. The management overheads required and the planning and forethought needed to successfully pilot new ways of working calls for such approaches to be factored into a software development project at an early stage.
Fred Brooks, author of The Mythical Man Month, was right when he said that you can not make a software project that is running late finish earlier by adding more people.
Anyone wanting to shake up their project management processes should be thinking ahead and treating this as a long term strategy - not a short term fix.
This was first published in September 2007