Distribute Development and the Quality Will Suffer
‘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
- General communication and collaboration challenges
- Software quality issues due to variable level of skills between locations
- Political issues with the way organization is structured
- Quality concerns due to difference in processes/practices
- 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.
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.
Re: agree fully.
like OSS but not quite like OSS
How you distribute matters...
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.
"Business Acceleration through Process Automation."
John Krewson, Steve Ropa and Matt Badgley Nov 24, 2014