Distribute Development and the Quality Will Suffer

Posted by Vikas Hazrati on Dec 19, 2008

Sections

Process & Practices

Topics

Agile in the Enterprise ,

Agile

Tags

Distributed Team ,

Surveys

‘Software quality issues due to variable level of skills between locations’ was one of the most interesting findings which came out of an survey, which was performed by The Reg reader poll in September 2008. The survey was conducted with 369 respondents, of whom, 80% had direct experience with distributed software development. The geographic split being 44% UK, 36% USA and 20% elsewhere.

Though, communication and collaboration was still the dominant challenge in distributed development with more than 85% respondents mentioning it, the surprise second, as per the survey, was software quality issues arising from too much variation in skill sets between sites. Another closely related concern was the difference in quality of practices and processes. These challenges remained true irrespective of the type of organization and management approaches followed. Three main approaches, used by the respondents, in distributed development were

• Hub and Spoke – Core development function surrounded by geographically distributed teams
• Peer to Peer – All activities divided between teams of equal status
• Ad-Hoc – No consistent policy and a mix of various approaches

The survey revealed that the challenges of distributed development are amplified when an Ad-Hoc approach is followed, however, the order of challenges was similar across the approaches. The top 5 challenges reported across approaches were

1. General communication and collaboration challenges
2. Software quality issues due to variable level of skills between locations
3. Political issues with the way organization is structured
4. Quality concerns due to difference in processes/practices
5. Project management issues caused by complexities of distributed development

The primary motivation behind distributed development came out to be resource flexibility and strategic value as compared to cost. This might lead to an observation that just focusing on cost does not help because cheap remote resources might translate to inadequate experience and skill.

Another interesting observation was the result of the activities, which can be distributed. Respondents, who followed Hub and spoke approach, preferred distributing coding and testing activities more than some critical activities like specification definition and analysis and design. Those following peer to peer approach were relatively less reluctant to distribute these critical activities.

In a similar analysis, Scott Ambler summarized the results from the Dr. Dobb's 2008 Agile Adoption Survey, which showed that the success rate of the project is inversely proportional to the geographic distance. Following were the success rates for Agile teams,

• Collocated – 83%
• Near located – 72%
• Far located – 60%

According to Scott, the key enablers of distributed development, which help both communication and skill development are

• Getting the whole team together at the start of the project
• Some initial upfront modeling to build comparable skills
• High-level planning to identify their major dependencies and milestone dates
• Organization of team structure around the architecture, so as to reduce the communication required between various sub-teams
• Better tooling than collocated teams because index cards, cork-boards, and white-boards don't work well from a distance.
• Have ambassadors and boundary spanners.

There are other success stories like Offshore Development by Martin Fowler and Reaching Hyper-Productivity with Outsourced Development Teams by Jeff Sutherland which talk about good practices for successful distributed development.

Though, distributed development has its own set of challenges but it is a reality in today’s world. The key lies in effective tooling and better collaboration practices which would help in facilitating communication and building skills across geographies.

1. Back to top

   agree fully.

   by Jay Dub

   Having spent 3 years as a developer on a shared codebase across 3 distributed teams (8 hours apart) I think the quality of the code was the major victim. Although I do not neccesarily think it is down to skillset - more culture. All 3 teams were practicing TDD and refactoring as good as we could. The major problem was a common architecture - we did not have a common metaphor of what the system would be and therefore it became everything and anything with no real layers or subsystems.
   
   As a result it turned into a big ball of mud that is effectively un-refactorable.
   
   The few attempts we had to 'break out' sub-systems of code were abandoned. Although one was particularly successful (albeit painful) and led to a new suite of products.

   Reply

2. Back to top

   Re: agree fully.

   by Vikas Hazrati

   Jay, that sounds in agreement with what Scott has to say that you should structure your efforts and teams around a common architecture. So agile or no-agile I guess the design and architectural concepts should still be strong for the project to be successful and less painful. After all as I see it Agile (process) is only 1 part of the pie. It has to be complemented well with both technology and people. With the right technology and people, Agile acts as a catalyst to get things done better and faster.

   Reply

3. Back to top

   OSS?

   by Bill Burke

   Open Source Development has been a pretty good distributed model for development. I think the problem is that people try to enforce a local model into a distributed development team. Most developers are used to white-boards rather than discussing design and coordinating over email. So maybe the problem is Agile not distributed development.

   Reply

4. Back to top

   like OSS but not quite like OSS

   by Andrus Adamchik

   As somebody who's personally and actively involved in both OSS and organizing offshore dev, I'd say parallels with open source only go that far. The infrastructure and communication channels are clearly the same. The difference is in developer motivation. Open source project participants are self-motivated individuals who already have a clue what to do and a personal reason to be involved. When you have an offshore team, the whole process becomes about getting the developers understand and feel the problem domain of a far away customer. As opposed to open source (a developer is having an itch to scratch), people are working with abstract problems that have no bearing to their everyday lives. That becomes the biggest problem to solve.
   
   Andrus Adamchik
   objectstyle.com

   Reply

5. Back to top

   How you distribute matters...

   by Zubin Wadia

   Geographical distribution definitely affects code quality. Additionally, when the Architects are not geographically located in the same place as the developers - implementations are not true reflections of the design/vision. So yes, distributed models definitely introduce noise into the process. However, most projects don't require pinpoint execution and you can get away with some dilution as long as teams communicate, proper checkpoints are enforced and effective reasoning is the basis of compromise.
   
   Also, don't break the project up into tier-specific teams - this will only promote dilution and confusion. Each development team should be responsible for their vertical functions and be able to execute across all tiers of the project. This gives you some fail-over when life/politics/economy intervenes with the implementation as you can introduce new functionality to a team familiar with all aspects of the architecture. Learning a new technology tier and its dependencies and interactions however, is not so simple, especially with distance.
   
   If the project is small enough and the execution window isn't absurd - we generally prefer keeping Architecture/Business-Analysts on one shore (the clients) and the entire Development team on another shore (whether the shore is 200 miles or 9000 miles away is irrelevant). The Architects regularly visit the offshore group, interact with them personally - especially at the beginning of the project when the vision and expectations need to be set. Depending on time and budget, we sometimes send our Business Analysts for brief visits as well. Don't ever blind-side your developers - having them in-step with the vision is the key to successful execution.
   
   Cheers,
   
   Zubin Wadia
   CTO
   www.imagework.com
   "Business Acceleration through Process Automation."
   
   Blog:
   zwadia.com

   Reply

• Older >