Distributed Development (Part 2)
Last time, I talked about all the challenges that surface when you attempt distributed software development, that is, having an IT project team being spread out over a wide geographical area. Simply put, it’s tough to do well, if at all, for a variety of reasons, including problems with communications among developers, maintaining conceptual unity of the system itself and managing a dispersed team.
Nevertheless, you may have strong reasons to do distributed development; in some circumstances, you may have no other choice economically, politically or otherwise. So if you’re doing to do it, how can you increase your chances of success and quality?
Besides my own experience on several projects with distributed development, ranging from a software startup to the global Iridium satellite telephone project, I solicited feedback from two long-time colleagues—Bruce Henderson and Deirdre Poeltler—and also got comments on the same subject on one of my Web sites. Here’s a summary of the key factors for achieving success in distributed development.
1. Use your best IT engineers for remote development.
I have written elsewhere about the attributes that make up an outstanding IT engineer: talent; education; professionalism; experience; and skill (“TEPES”). If you have individuals or small teams that are working remotely, you want to be sure these are your best people. Note from the list of attributes that “best” doesn’t necessarily mean “brightest” – it means most disciplined, trustworthy and self-motivated. You want people who can get the job done with a minimum of supervision and management, and who have a desire to do well and look good.
2. Small is beautiful.
As a commenter on my Web site noted, overall project staffing size is a key factor in success: The fewer people involved, the more likely the project will succeed. Of course, the irony is that the smaller the team, the more feasible it would be to relocate them to all work under one roof in the first place, but still, keep the size factor in mind.
3. Bring the team(s) together as often as needed.
Building a cohesive development team is difficult enough when all the members are under the same roof; it’s that much harder when there’s significant physical separation. Set a regular schedule to gather everyone at one location, and make sure that there’s time for socialization; you want your team members to like and trust one another as much as possible. If the project is too large to truly bring everyone together, then make sure you bring key personnel from each team together. Note that in the relatively short period—less than six months—that I worked on the worldwide Iridium project, I attended two such meetings: one in Phoenix for representatives of all North American teams and one in Hong Kong for representatives of the entire global effort.
4. Provide outstanding and appropriate infrastructure.
If you’re going to distribute your project, make sure the people involved have the hardware and software tools they need—not just for development, but for communications as well. This includes appropriate distributed (and likely Web-based) tools for configuration management and source code control, defect tracking and change management. It also includes tools such as headsets, webcams and desktop sharing software, so that person-to-person conferences can take place with little or no notice and with high bandwidth.
5. Organize the distributed team around the system architecture.
Conway’s Law says that the system design reflects the communication structure of the teams that build it. A distributed development effort is only going to intensify that effect. Henderson noted that at one large military project he was involved with, there was a great deal of effort up front to partition the system into reasonable stand-alone chunks, document the operational concepts and interfaces, and then pass those chunks out to the various distributed groups.
6. Create one-on-one development coordination links.
The natural inclination would be to have as many people talking to one another as possible, but that can actually be counterproductive. Poeltler had the experience of both being the remote developer on one project, and later hiring and managing a remote developer on a completely different project. She noted that in both cases, a critical success factor was that the remote developer had a single point of contact within the overall team. When she was managing a remote developer—located at his home in Hawaii—she worked hard to shape him into her “doppelganger,” so that his independent work would mesh with her overall system architecture. For the last two points together, think “high cohesion, loose coupling.”
7. Focus on software quality assurance.
Too often, SQA is the poor relation of software engineering, an underfunded afterthought and mostly defined just as testing (it’s much, much more than that). SQA is even more critical on distributed projects, because the demands and pitfalls are greater. Henderson noted that there were significant problems with the first integration attempt of the distributed military project mentioned above. The individual modules tested out quite well, but the end-to-end and integrations tests did not. However, the overall lifecycle approach was iterative, so system integration improved each time around.
Some of you are no doubt thinking that most of these suggestions apply to regular, nondistributed development projects as well. For the most part you’re right, although they are quite often neglected there as well. My point is that these suggestions are far more critical with distributed development. That is, your chances of failure are much higher if you neglect them in a distributed project than if you neglect them in a nondistributed one.
© 2008 Bruce F. Webster