Collaborative Software Engineering Especially in Disparate Geographical Environments Philip Kelley.

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

• >= 2 isolated engineering teams of >=1 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 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

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

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 didn’t 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 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!

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 developersR

educ

e in

tera

ctio

n

Manage interaction better.

Workplace IM (and IRC)• Versus actually visiting someone’s

office. Incredibly important with geographically separated teams.

• Reduce required interaction– By reducing cost of contacting another

individual. Don’t 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 interruptee’s office

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.

Team 1 Private Branch

Team 2 Private Branch

TRUNK

Reverse integrate (trunk->branch)Integrate (branch->trunk)

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 one’s 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 identified.

This applies to geographically separated teamseven more because problem bugs happen moreoften when developers don’t 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 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

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 tooltips

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

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)