Project Spotlight: Teaching Students Global Software Development

Tapping the talents of a globally based team of programmers promises the alluring image of efficient, around-the-clock application development. But as these students learned, time conflicts, power outages, and over-commitment can get in the way of a good idea.

• By Dian Schaffhauser
• 03/07/11

What's the best way to prepare students for global software development work? A project in 2009 at three universities--one in New York, another in India, and a third in Senegal--set out to explore that question on a small scale. What they learned? If technology doesn't get in the way of progress, grappling with time zone differences and varying levels of access to reliable electricity do.

Armed with funding from IBM and Sun Microsystems, instructors Christelle Scharff, an associate professor of computer science at Pace University, Olly Gotel, an independent researcher, and Vidya Kulkarni, in the Computer Science Department at the University of Delhi in India, enlisted five master of computer science students--one from Pace, two from U Delhi, and two in Senegal's Ecole SupÈrieure Polytechnique--to tackle a short development project. The professors reported on their experiment in a paper, titled "Transitioning to Distributed Development in Students' Global Software Development Projects: The Role of Agile Methodologies and End-to-End Tooling."

Collaborative Efforts
In the past faculty members had tried out various models of collaboration, in which specific project roles were distributed to as many as 60 students, with teams divvied up by role and geographic location, but fairly site-specific. In those projects the developers used a "loose" waterfall process, according to Scharff. In that model, each phase of the development work moves from one to the next in sequence, from requirements definition to design, to coding, and so on.

Participants also used an assortment of programming tools. That included open source tools Eclipse, a Java-based integrated development environment; JUnit for unit testing; and Subversion for version control. The community site Java.net was used for bug reporting. To communicate with each other, the students used asynchronous mailing lists, real-time online chats, and virtual world Second Life. They used wikis to maintain code and other files related to the work.

The emphasis of the work varied from year to year with focuses on infrastructure, software quality, supply chain management, socialization, and other components of the global programming scenario. But the challenges followed a pattern. Students tended to focus on local team needs more than distributed team needs. Students required a lot of training for the tools, and the use of so many different tools slowed the learning curve. Different groups of students went their own direction in creating variants of the software.

Also there was a scenario missing in all of those variations--one in which the students developed an application together. That's what the researchers wanted to explore next.

The Real Test: Mobile Phone App Development
The project they undertook in 2009 was to develop a mobile phone application for use by young children to practice math, reading, writing, and geography. It lasted nine weeks, with three weeks of training and six weeks of development work. The students who had volunteered for the mission all had different goals. The Pace student wanted to learn more about project management across borders. The students in India were intrigued by doing mobile development for a global initiative. The Senegal students were interested in mobile development in a global team as well as the programming methodologies they'd be using, Agile and Scrum.

Target First Grade, the app at the center of the initiative, could be used in developing countries where class sizes can reach 60 to 80 students and teachers are hard-pressed to give attention to any one of them. Also, the app addressed budgetary restrictions; schools could more easily afford cheap mobile phones for student use than computers. The app, in both English and French, would deliver open-ended and multiple-choice questions that the young student could practice on; and then the app would score responses.

In agile programming, iterations of code come fast and furious, and developers work closely with their users, continually adjusting the results until they match what the users have in mind for the program. Scrum is a framework for managing the project and has its own vernacular. A "scrum master" leads the team and helps resolve issues; "user stories" describe program requirements; iterations of development, known as "sprints," last one to four weeks; the team meets daily to share what each person has finished, what's to be worked on next, and what's standing in the way.

But the methodology required tuning to fit into the format of this project. For example, the team was in three continents with conflicting time zones, and the students had other commitments, all of which conspired to prevent daily real-time meetings. So the project set some guiding principles, such as that communication would be important for creating visibility and improving decision-making; those daily scrum meetings would be handled in writing. And in order to build trust with each other, team members would prioritize work, deliver what they committed to, and deliver them reliably.

Tool Selection
Also, the team would reduce the number of tools it employed for the collaborative development process. Since the volunteers were familiar with Eclipse, the instructors chose IBM's Rational Team Concert, which is built on Jazz, an ongoing IBM-sponsored, community-created extension of the Eclipse development environment for team use.

The idea was that the team would use Rational Team Concert to maintain the deliverables from their Scrum meetings, as well as versions of the software, to share code, to track bugs, and a number of other activities related to the project. A wiki alerting function could facilitate communication to members as code was checked in or out and artifacts were added to the Rational development repository. The program also provided for project reporting in order to help the team stay on top of project health and progress.

"The only thing we had on the top was the use of Google Groups and Chat for communication between the members," said Scharff.

The team also used the EclipseME plugin, which provides functionality specific to mobile application development.

What Students (and Faculty) Learned
According to Scharff, the process definitely resulted in student learning. "They learned how to use a collaborative tool; they learned about Scrum; they learned about mobile app development. These are things that are not straightforward," she said. But, she added, they also learned about "the difficulty of communication in a distributed world."

As she noted, American students had to meet with the team at 7 a.m. Eastern time, which was noon in Senegal and 6:30 p.m. in India. "You could not do the inverse. You could not meet in the [United States] in the evening because that was too late for Senegalese students."

Scharff said the students had a painful lesson in the difficulties of unreliable infrastructure. "The students in Senegal sometimes don't have electricity. That created some frustration. In India, they had problems with the Internet at some point. "They learned a lot about working with others and being understanding and--yes, you cannot say, 'Let's meet in two hours.' If you wanted five students to be online at the same time, you had to do planning," she added.

Some of the students were more responsive to other members. "In Rational Team Concert you can put that you're on vacation. At some point, students disappeared, but didn't say if they were on vacation or doing exams. So there was some frustration there," Scharff said.

Also, the students had difficulty using the version control aspects of Rational Team Concert. "It was more difficult than using Subversion," Scharff said. "That was a problem for the students during the project."

And that obstacle pointed to a change the students admitted they'd make were they to go through a similar initiative again: They'd do a better job of studying the materials provided by Scharff before the project began. The Pace instructor had shared a list of reading resources and put together videos to explain how the software worked before the start of the effort. "All this was provided to them. They had to do some reading, watch videos, and so on, so they were really aware of what they were doing. It was not enough," she acknowledged.

As a result of the challenges, some of the principles set in place at the beginning of the work faltered with time. For example, Scrum meetings didn't take place daily. That in turn led to confusion about the status of individual deliverables. Also, the developers ended up not working as one team so much as three teams. Nor did they get the chance to test each other's work; they could only test their own work.

From the instructor perspective, the endeavor pointed out another problem: The students don't necessarily pay attention to the instructions coming from somebody who isn't at their school. "That's the most difficult scenario and most risky from the instructor perspective, because the students are not my students," Scharff said. "For example, I cannot go there and just tell them, 'OK, you didn't do the work.' Everything is by e-mail. My students--I can tease them and push them. But if there are students somewhere else, it's more difficult."

Scharff said she'd like to return to the project do some refinement of the mobile app and repeat the exercise of student collaboration across global locations. But that'll require following some new practices. For example, instructors will be more proscriptive about the Scrum roles played by each participant. They'll also make sure to use a "process coach" again and give feedback to the team on a regular basis to help ensure success. They'll include an organizing meeting so that students can learn about each other before the work begins. And they'll set rules about communicating absences and being responsive and responsible to other team members.

One decision she's also made: The project will involve a "minimal set of tools" for the work, such as Rational Team Concert, since "this will permit students to become productive quickly."