Stephan Salinger

Saros: an eclipse plug-in for distributed party programming

This paper describes the social practice of distributed party programming as a natural extension of pair programming in a distributed context with two or more software developers working together. To this end we provide an overview of the Eclipse plug-in Saros, a software implementation supporting this practice, and explain its technical architecture. The central contribution of this paper is a detailed description of four concrete scenarios of distributed collaboration where one of them is distributed party programming. Furthermore it will be shown how each scenario is supported by Saros. The paper closes with a discussion of preliminary findings about establishing Saros in Open Source projects.

Doing Scrum Rather Than Being Agile: A Case Study on Actual Nearshoring Practices

Previous research in the field of Agile Distributed Software Development often focused on the a synchronicity of working hours due to different time zones, as if this was the only risk when developing software in non-co-located environments. This case study reflects a near shoring setting in which this primary impediment does not exist and investigates a broader range of risks now standing out more clearly. We observed two Polish Scrum teams working for a German company, which has been successfully applying Agile Methods for over four years. We present the actual process and practices of the external teams and contrast them to the intended way of proceeding. Main result: Agile near shoring is feasible and may produce high satisfaction amongst Product Owners, but this satisfaction might be delusive if process deviations due to misunderstandings of what Agile development means go unnoticed.

Liberating pair programming research from the oppressive Driver/Observer regime

The classical definition of pair programming (PP) describes it via two obvious roles: driver (the person currently having the keyboard) and observer (the other, alternatively called navigator). Although prior research has found some assumptions regarding these roles to be false, so far no alternative PP role model took hold. Instead, most PP research tacitly assumes the classical model to be true and thus PP to be no more difficult than solo programming. We perform qualitative research (using Grounded Theory Methodology) to find a more realistic role model, and have uncovered a suprising complexity: There are more than two roles, they are assumed and unassumed gradually, multiple roles can be held by one person at the same time, and some of their facets are subtle. Mastering this complexity requires specific PP skills beyond mere programming and communication skills. By ignoring such skills, previous PP studies (in particular the controlled experiments) have investigated a rather mixed bag of situations, which explains their heterogeneous results. The emerging result is that qualitative research on the PP process will lead to constructive behavioral advice (process patterns) for pair members and to more meaningful designs for quantitative PP research.

Distributed-pair programming can work well and is not just distributed pair-programming

Background: Distributed Pair Programming can be performed via screensharing or via a distributed IDE. The latter offers the freedom of concurrent editing (which may be helpful or damaging) and has even more awareness deficits than screen sharing. Objective: Characterize how competent distributed pair programmers may handle this additional freedom and these additional awareness deficits and characterize the impacts on the pair programming process. Method: A revelatory case study, based on direct observation of a single, highly competent distributed pair of industrial software developers during a 3-day collaboration. We use recordings of these sessions and conceptualize the phenomena seen. Results: 1.Skilled pairs may bridge the awareness deficits without visible obstruction of the overall process. 2.Skilled pairs may use the additional editing freedom in a useful limited fashion, resulting in potentially better fluency of the process than local pair programming. Conclusion: When applied skillfully in an appropriate context, distributed-pair programming can (not will!) work at least as well as local pair programming.