Collaborative Software Engineering Especially in Disparate Geographical Environments - PowerPoint PPT Presentation


PPT – Collaborative Software Engineering Especially in Disparate Geographical Environments PowerPoint presentation | free to download - id: 6ec4bf-YmJkY


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Collaborative Software Engineering Especially in Disparate Geographical Environments


Collaborative Software Engineering Especially in Disparate Geographical Environments Philip Kelley – PowerPoint PPT presentation

Number of Views:42
Avg rating:3.0/5.0
Slides: 23
Provided by: Phili378
Learn more at:


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Collaborative Software Engineering Especially in Disparate Geographical Environments

Collaborative Software Engineering Especially in
Disparate Geographical Environments
  • Philip Kelley

Software Engineering
  • More than 1 person ? collaborative effort
  • F.P. Brooks Mythical Man Month, No Silver Bullet
  • Can even be hard to coordinate 2 people
  • Moving to geographically isolated teams
    aggravates the problem

More collaboration
In Disparate Locations
  • gt 2 isolated engineering teams of gt1 people
  • Open source team size of 1 is common
  • Inter-team collaboration limited to software
    tools and the telephone
  • Time zones, workday overlap

In Disparate Locations
  • Herbsleb, et. al. (Bell Labs) studied a
    development project at Lucent with 2 primary
  • A lot of things went wrong on the project
  • Components built at multiple sites did not work
  • Collaboration did not just have to occur between
    the 2 primary sites
  • The teams depended on substrate components
    developed at many other sites

What went wrong?
  • Site teams tried to work on unrelated parts of
    the project
  • This was a good idea
  • But, assumptions were made by each of the sites
    about the semantics of the interfaces between
  • Even the unit tests at each site made these
  • Each team was certain their component was
    semantically correct, but the documentation was
    just inadequate

What went wrong?
  • Different change management systems were used at
    different sites
  • This enabled rapid progress early in the
    development cycle
  • But during the integration phase, when things
    didnt work, this caused trouble
  • Bug fixes, etc. had to be replicated in both
    tracking systems, wasting a lot of time

What went wrong?
  • Can these issues be addressed by collaborative
  • Easier ones identified by Herbsleb, et al
  • The high cost of initiating contact
  • Integrated development environment, i.e. same
    version control repository, same change
    management system
  • Hard ones identified
  • Cultural differences between teams
  • Trust issues between teams
  • Lack of unplanned contact with other team members
  • Time zones!

Ideal Software Engineering Environment
  • Obvious goal Reduce the percentage of developer
    time spent on coordination of efforts with others
  • Many tools already exist
  • Version control - Change management
  • Automated build - Workplace messaging
  • Static analysis
  • An ideal environment would have all these
    integrated together
  • Can roll your own, developing procedures to
    integrate pieces together
  • Visual Studio Team System from MS is an option

Ideal Software Engineering Environment
  • In addition to the standard toolbox there are
    some novel ideas for software development tools
    which we will look at
  • Two ways for tools to work
  • Manage the interaction between developers better
  • Reduce the required interaction between developers

Reduce interaction
Manage interaction better.
Workplace IM (and IRC)
  • Versus actually visiting someones office.
    Incredibly important with geographically
    separated teams.
  • Reduce required interaction
  • By reducing cost of contacting another
    individual. Dont have to get up (or fly to
    another country!)
  • Manage interaction better
  • Interruptee can multitask IM sessions, and delay
    response if needed to preserve his/her train of
    thought, etc.
  • Drawbacks
  • Interruptee can completely ignore IMs
  • Interrupter can get higher-quality support from
    the interruptee by walking into the interruptees

Version Control
  • A (partially) disconnected filesystem
  • Advantages are better realized when coupled with
    the change management system

Version Control
  • In the case of geographically separated teams,
    the same version control system should be used
    for both sites.
  • But, each team could work out of a separate
    branch, and merge changes at regular intervals.
  • This provides insulation from breaking changes on
    the other end, but prevents divergence of the
    branches from becoming irreparable.

Reverse integrate (trunk-gtbranch)
Integrate (branch-gttrunk)
Team 1 Private Branch
Team 2 Private Branch
Change Management
  • A system for tracking requests for changes in the
    software being built
  • The same system and database should be used for
    all sites
  • Ideally, version control should be integrated
    with change management.

These screen shots are from Visual Studio Team
System. I have seen other solutions, however,
using Perforce and other change management
systems. Integration capability is a main selling
point of all these tools because the advantage is
well understood, but only in the past few years.
Social Issues with Change Management
  • Halverson, et al. (IBM Research) did a study of
    change management in two public projects, Mozilla
    and Eclipse
  • They found social problems with change management
    when developers were separated geographically
    from the bug reporter.
  • It is easy to ignore bugs
  • It is easy to reassign bugs to another developer
    to reduce the number of bugs on ones own plate
  • It is easy to claim an issue is not a bug
  • This is a situation where the goal is not to
    reduce the amount of required interaction, but to
    manage it more effectively. Management should be
    made aware of these sorts of social problems when
    they occur on their software development teams!

Halverson, et. al. (IBM Research)
The novel solution presented was better
visualization of change management data. When a
bug is deep orange, it is open and assigned. Look
how many times bug 1 has been opened and
reassigned! This is something management can
easily see when looking at a bug database.
Problem bug and problem developers can be
This applies to geographically separated
teams even more because problem bugs happen
more often when developers dont know each other.
Halverson, et. al. (IBM Research)
  • Bugs have priority values but also have a heat
    value that is based on age of the bug as well as
    other factors
  • Easy to spot bugs which are standouts due to high
    heat value.

Leveraging Integration in our Ideal Software
Development Environment
  • Enforcement of policies for the use of available
  • Ex. Cannot check in a changeset that does not fix
    a bug, if the time until release of the product
    is near
  • Ex. Cannot check in a changeset without running
    static analysis tools on the code
  • Can also use the version control system and
    change management system together as a source of
    data to be mined

Querying the Database
  • Cubranic, et al. U. of B.C., CSCW 2004
  • Hipikat is a tool for querying work item
    tracking, version control, and source code
    indices for a string
  • Hipikat returns nuggets of information, such as a
    previous change request, or a piece of source
    code with comments that match the string. Each
    nugget has a confidence value
  • Hipikat understands the inheritance structure of
    classes used in an object-oriented program, and
    uses this information to aid in its suggestions

Querying the Database
  • Cubranic et al. believed that questions could be
    answered by project history, as represented by
    this database
  • With similar effectiveness to asking a colleague
    for help
  • This strategy reduces required interaction
    between developers, and especially helps with
    geographically separated sites, where the cost of
    contacting another developer is high

Querying the Database
  • Two groups of people were asked to add
    functionality to Java breakpoint tooltips in the
    Eclipse debugger.
  • Group 1 Had Hipikat. Experienced programmers who
    had never worked on Eclipse.
  • Group 2 Did not have Hipikat. Experienced
    Eclipse programmers that had never worked on

Querying the Database
  • The experimental results?
  • Both groups did fairly well.
  • The non-Eclipse programmers did a little better.
    Why? Because Hipikat provided them with an
    inheritance picture that showed how a parent
    class was also involved in the correctness of the
  • So, integration and use of past knowledge helps
  • Can reduce the number of times one has to ask for
    help, especially for new developers to a team
  • In some cases, can even go beyond what one would
    get by asking a friend, as in the example where
    Hipikat helped developers to understand the
    superclass involvement.

  • Geographically separated software development
  • Is the future
  • Is already here
  • Many problems arise with geographically separated
    software development
  • Only some can be easily addressed by
    collaborative tools in an ideal software
    development environment
  • Two main strategies for tackling the problems
  • Reduce the amount of interaction between
  • Better manage the interaction between developers
  • In any case we are only reducing software
    development headaches by a constant factor
  • No silver bullet (Brooks)