Philips experiences in global distributed software development

About the paper:

1.This paper describes the experience of over 10 years of global distributed development at
 Philips, derived from about 200 projects.
2.Team coordination and communication, requirements and architectures, integration,
configuration management.
3.Subcontracting software development needs selection of suppliers, specification of the
work to be subcontracted and establishment and content of the contract.

Benefits of globally distributed development:
Shortening time-to-market cycles by using time zone differences ,
Improving the ability to quickly respond to local customer needs,
Allows organizations to benefit from access to a larger, qualified resource pool with the
promise of reduced development costs, and
Innovation:  mixing of developers with different cultural backgrounds may trigger new ideas.

Problems in globally distributed development:
1.Poor visibility and control of remote activities.
2.Inadequate communication, collaboration and coordination across individuals, teams, time-zones and projects.
3.Insufficient (or lacking) knowledge and asset management capabilities.
4.Language and cultural differences.
5.Trust factors.
6.Lack of shared contextual awareness.

Distributed development can be a purely ‘in-house’ (single company, multi-site)
activity or it can also involve customer-supplier relationships.

The problems encountered in Philips multi-site software development have been
grouped in the following categories:
1.Team coordination and communication
2.Managing requirements and architectures
3.Integration
4.Configuration management

Problems encountered for Team Coordination and Communication:

 Basic management capabilities were not present in teams,
 Dependencies between teams were not made explicit and managed,
 Acceptance procedures of mutual deliveries were not defined,
 Status of teams was not pro-actively checked,
 Escalation mechanisms were not defined,
 Learning curve was underestimated,
 Need for explicit communication was underestimated, and
 Loss of efficiency due to multiple teams.

Problems encountered for Managing Requirements and Architectures:
High impact of unstable requirements,
 No unified understanding of requirements and architecture was reached, and
 Architecture status was not managed.

Problems encountered for Integration:
Responsibilities were not assigned clearly and integration strategy and plan were missing.
 Integration effort and time were underestimated.
 Required knowledge and skills were not present in integration team.
 Integration was not centrally controlled.

Problems encountered for Configuration Management:
Not enough preparation time taken to set up CM infrastructure.
 Competent configuration managers were not available.
 Change management procedures were not defined.

Lessons Learned:
1.GDD has in practice been two to three times more costly compared to one-roof
 development.
2.Exchange of knowledge and practices are experienced.
3.Particular attention should be paid to the preparation and management of team
coordination and communication, requirements and architectures, and also integration
and configuration management.
4.GDD improves time-to-market and customer request response efficiency along with
access to greater and less costly resources.

Global software development and delay: Does distance still matter?

GOALS

1.Study of communication structures and delay, as well as task completion times in IBM’s
 distributed development project Jazz.
2.Exploring the effect of distance on communication and task completion time.
3.Used social network analysis to obtain insights about the collaboration in the Jazz project.
4.Findings in the light of existing literature on distributed collaboration and delays.

Paper consists of the following:
1.Challenges in distributed communication.
2.Effects of distribution on communication delay
3.Communication structures and task completion times.
4.The study settings, the data constructs and the data collection.
5.The analysis, and results are discussed.
6.Possible threats to validity are discussed.

Study settings done for the analysis of JAZZ project:

1.Its development involves 16 different sites that are located in the United States,
 Canada, and Europe.
2.Functional units->team lead->leads report to a project management committee ->
 project-wide coordination.
3.It uses the Eclipse Way process.
4.Every team has an iteration plan that consists of unstructured text and task descriptions,
which are captured in work items.
5.Commenting on the work items, chat, email are means of communication.

Communication and task completion in distributed teams:
1.Geographical distance introduces not much significant delays in communication and task
 completion.
2.Variations in communication and task completion times cannot be at all associated with
the variation in geographical distance of collaborators in the project.
3.The expectation that larger distribution, as found in collaboration involved a higher number
of sites, is associated with an increase in both response and work item resolution times,
was not confirmed in this study.

Threats to validity:
1.Sources of information  such as email lists, chat, web-based information and
face-to-face meetings were not considered.
2.Author believed that comments are most commonly used method to communicate
about work items.
3.Conceptualization of response time assumes that every comment on a work item is a
 response to the previous comment on that work item.
4.The resolution time might also include possible idle time, i.e. the time between the
 creation and the actual time when someone starts working on the task described by the
work item, which is not considered.

Lessons learned:
1.Distance does not have as strong of an effect on distributed communication delay and
task completion.
2.Asynchronously comment on and tracking activity of work items, mitigate the effect
of distance.
3.The mechanism of a shared repository and associated comments from members facilitates
 knowledge exchange and aids expertise seeking.

Group Awareness in Distributed Software Development

In OSS people hardly meet face to face and get into adhoc communication.This leads to lack of
coordination and communication.
Some of successful OSS are Linux, Apache, OpenOffice application suite.
Permission to make digital or hard copies of all or part of OSS for personal or classroom use is
granted without fee provided that copies are not made or distributed for profit or
commercial advantage and that copies bear this notice and the full citation on the first page.
It suffers from the problem of uncoordinated changes to the same file or module.

Paper address the issue that how distributed developers maintain group awareness.
A study was carried out of open source teams to determine whether-
*developers need to stay aware of one another,
*what awareness information developers keep track of
*how they gather and maintain their knowledge

Group awareness is useful for coordinating actions, managing coupling, discussing tasks,
anticipating others’ actions, and finding help.
Three mechanisms help people to maintain awareness in co-located situations are:
*Explicit communication.
*Consequential communication.
*Feed through.

lack of ad-hoc communication between software developers cause an increase in
coordination problems and a decrease in collaboration between remote sites.
Newsgroups, email, text chat, and instant messaging are ways of communication

The main benefits of group awareness would be in simplifying communication and
improving coordination of activity.
Software systems involve dependencies and linkages.
Two ways(menationed in paper) to reduce dependencies are:
By reducing the number of developers.
By strongly partitioning the code.

The paper investigates 3 OSS projects and interviews developers and so When asked them
whether they primarily work in a ‘home’ area in the code, most of them said that they had
worked in a variety of areas, and were able to “hop around” following their interests as
ownership can cause as many coordination problems as it solves.

Following is used for general awareness-
1.Mailing list
2.Text chat
3.Commit logs

Pros and Cons of mail lists and text chats:
1.people are not socially required to respond and so the top experts do not become flooded
with questions.
2.If the senior developers are too busy to answer all questions themselves, they watch who
does respond and check the answers.
3.There is social pressure to be correct.
4.Developers are committed to reading the list

DOES AWARENESS WORK?

From the perspectives of the developers it is essential because of the following:
Someone committing something which essentially duplicated what someone else was doing.
People have to always manage to work together on related things, sometimes in tightly
coupled teams.

Problems preventing group awareness:
1.A better project lists(of who works in what area) that could be automatically kept up to date.
2.People wanted a better way to decide (based on areas of work) which developer should
asked to handle particular bugs as they are reported.
3.Complaints about being able to stay aware, find people when needed, communicate
 effectively, and coordinate plans and actions.

Two Case Studies of Open Source Software Development: Apache and Mozilla

HISTORY OF OSS:

*IBM , in the 1960s, came with some software which was free i.e. libre, an OSS.
*In late 1970s and early 1980s, two different groups were establishing the roots of the
 current open source software movement:
1.On the US East coast, Richard Stallman, formerly  a programmer at the MIT AI Lab,
resigned, and launched the GNU Project and the Free Software Foundation.
2.On the US West coast, the Computer Science Research Group (CSRG) of the University
of California at Berkeley was improving the Unix system, and building lots of applications
which quickly become BSD Unix.

Examples:
Apache (widely used as a WWW server),
Perl (an interpreted language with lots of libraries),
XFree86 (the most widely used X11 implementation for PC-based machines),
GNOME and KDE (both providing a consistent set of libraries and applications to present the
casual user with an easy to use and friendly desktop environment),
Mozilla (the free software project funded by Netscape to build a WWW browser).

Differences b/w OSS and other kind of devpt:

1.OSS systems are built by potentially large numbers (i.e., hundreds or even
thousands) of volunteers. It is worth noting, however, that currently a number
of OSS projects are supported by companies and some participants are not
volunteers.
2.Work is not assigned; people undertake the work they choose to undertake.
3.There is no explicit system-level design, or even detailed design [Vixie 1999].
4.There is no project plan, schedule, or list of deliverables.

Characteristics of OSS:
1.Developers never meet face to face,
2.Different geographic locations,
3.They cordinate via emails and bulliten boards,
4.Errors get rectified very quickly
5.Developers work on the part  they are passionate about.
6.Source code is available.
7.Open source developments typically have a central person
or body that selects some subset of the developed code for the “official” releases
and makes it widely available for distribution.

Study on Apache and Mozilla:

*Mozilla is a much bigger project of 78 modules , some of which are much larger than the
entire Apache project.

*Apache had about 6,000 MRs, 18,000 delta, and 220,000 lines of code added.

Comparision between mozilla and apache.