Working in pairs as a means for design knowledge building: an empirical study Gerardo Canfora, Aniello Cimitile, Corrado Aaron Visaggio RCOST- Research Centre on Software Technology University of Sannio, Italy {canfora, cimitile, visaggio}@unisannio.it Abstract Pair programming is increasingly attracting researchers’ and practitioners’ attention. One of the claimed benefits of pair programming consists of easing socialization among programmers, with the effect of transferring tacit knowledge. Designing software systems requires a strong employment of tacit knowledge, such as individual experience and skills. In this paper We explore the hypothesis that working in pairs can speed up and enforce the knowledge building process among designers. We name "pair designing” the application of pair programming concepts to the design stage. An experiment has been performed to test the effect of pair designing on knowledge building. This paper discusses preliminary results, which confirm the hypothesis of a positive effect of working in pairs on the process of knowledge building. 1. Introduction Knowledge to be applied when developing software includes explicit and tacit forms[1]. Software processes usually involve capabilities that are not only technical, but also related with personal attitudes and professional history, including creativity and experience. Creativity is difficult to assess both in qualitative and quantitative terms. However, experience can more readily be described by metrics and current literature reports some attempts in this direction [2, 3]. Explicit knowledge consists of concepts and practices that can be formalized and transferred by handbooks, scientific publications, documentation, tutorial, rules, and procedures. Tacit knowledge consists of the individual capability of solving problem, and it can be built basically by doing [5, 6, 7, 8]: applying explicit knowledge, registering personal observations, and making personal models for retaining it (interiorization in Naci Model [4]). This kind of knowledge cannot be easily formalized and transferred, except for the dialogue. Software design asks for tacit knowledge, generally speaking experience: as matter of fact, a software programmer becomes a software designer only after some years of practicing. Pair programming is a practice of extreme programming [9], where two programmers, working side by side, develop the same piece of code. One programmer, usually named ‘driver’, actively writes the code while other programmer, usually named ‘observer’, identifies tactical and strategic defects and issues. The roles are periodically switched. A claimed benefit of pair programming [10] is that it fosters knowledge leveraging between the two programmers, particularly tacit knowledge. It is claimed that this is due to discussing strategies and matters as they arise. The conjecture of the authors is that applying the practice of working in pairs to the design phase can facilitate the process of building design knowledge when contrasted with working as singletons. Similarly to pair programming, We name “pair designing” the practice where two designers work side by side at the same design document; one of the two actively edits the document whereas the second performs continuous review. To validate the conjecture an experiment has been designed and executed. The research goal is: to analyze a design task with the purpose of evaluating how pair designing increases the knowledge building with respect to solo designing from the viewpoint of the designer, in the context of an actual student project. The experiment presented in this paper focuses on student learning, rather than comprehension in practice. Executing experiments with students represents the preliminary phase of our investigation. It usually helps identify the most interesting issues to study and to fix bugs in experimental design before involving professionals. The paper continues as follows. Section 2 discusses related work. Section 3 describes the experiment, while results are discussed in Section 4. Finally, conclusions are drawn in Section 5. 2. Related Work When the term ‘pair programming’ was not yet widespread, Nosek investigated Collaborative Programming [11]. Collaborative Programming means Proceedings of the 12th IEEE International Workshop on Program Comprehension (IWPC’04) 1092-8138/04 $ 20.00 © 2004 IEEE