Collaborative Software Engineering Especially in Disparate Geographical Environments

1
Collaborative Software EngineeringEspecially in
Disparate Geographical Environments

• Philip Kelley

2
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
3
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

4
In Disparate Locations

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

5
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
  components.
• Even the unit tests at each site made these
  assumptions
• Each team was certain their component was
  semantically correct, but the documentation was
  just inadequate

6
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

7
What went wrong?

• Can these issues be addressed by collaborative
  software?
• 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!

8
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

9
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.
10
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
  office

11
Version Control

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

12
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.

TRUNK
Reverse integrate (trunk-gtbranch)
Integrate (branch-gttrunk)
Team 1 Private Branch
Team 2 Private Branch
13
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.
14
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!

15
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
identified.
This applies to geographically separated
teams even more because problem bugs happen
more often when developers dont know each other.
16
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.

17
Leveraging Integration in our Ideal Software
Development Environment

• Enforcement of policies for the use of available
  tools
• 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

18
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

19
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

20
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
  tooltips

21
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
  solution.
• 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.

Breakpoint
is-a
JavaBreakpoint
22
Conclusions

• 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
  developers
• Better manage the interaction between developers
• In any case we are only reducing software
  development headaches by a constant factor
• No silver bullet (Brooks)