Proceedings of WCRE '96: 4rd Working Conference on Reverse Engineering, 1996
... deleg.' shows precision values that would result if Paradigm Plus were able to d... more ... deleg.' shows precision values that would result if Paradigm Plus were able to detect all simple call delegations and our pattern rules contained checks for them, making most ... We conclude that the Pat system is a fast and simple way to recover design information from source ...
Page 1. SKaMPI: A Detailed, Accurate MPI Benchmark Ralf Reussner ... de Abstract. SKaMPI is a ben... more Page 1. SKaMPI: A Detailed, Accurate MPI Benchmark Ralf Reussner ... de Abstract. SKaMPI is a benchmark for MPI implementations. Its pur ...
ABSTRACT Context Root-cause analysis is a data-driven technique for developing software process i... more ABSTRACT Context Root-cause analysis is a data-driven technique for developing software process improvements in mature software organizations. The search for individual process correlates of high defect densities, which we call defect insertion circumstance analysis (DICA), is potentially both effective and cost-efficient as one approach to be used when attempting a general defect root cause analysis. In DICA, data from existing repositories (version archive, bug tracker) is evaluated largely automatically in order to determine conditions (such as the people, roles, components, or time-periods involved) that correlate with higher-than-normal defect insertion frequencies. Nevertheless, no reports of industrial use of DICA have been published. Objective Determine the reasons why DICA is not used more often by practitioners. Method We use a single-case, typical-case, revelatory-type case study to evaluate in parallel the importance of six plausible reasons (R1 to R6). The case is based on 11 years of repository data from a small but mature software company building a product in the high-end content management system domain and describes a four person-months effort to make use of these data. Results While DICA required non-negligible effort (R3) and some degree of inventiveness (R2), the most relevant roadblock was insufficient reliability of the results (R6) combined with the difficulty of assessing this reliability (R5). We identify three difficulties that led to this outcome. Conclusion Current repository mining methods are too immature for successful DICA. Gradual improvements are unlikely to help; different principles of operation will be required. Even with such different techniques, issues with input data quality may continue to make good results difficult-to-have.
Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement - ESEM '14, 2014
ABSTRACT Context: General knowledge transfer is often considered a valuable effect or side-effect... more ABSTRACT Context: General knowledge transfer is often considered a valuable effect or side-effect of pair programming, but even more important is its role for the success of the pair programming session itself: The partners often need to explain an idea to carry the process forward. Goal: Understand the mechanisms at work when knowledge is transferred during a pair programming session; provide practical advice for constructive behavior. Method: Qualitative data analysis of recordings of actual industrial pair programming sessions. Results: Some pairs are much more efficient in their knowledge transfer than others. These pairs manage to (1) not attempt to explain multiple things at once, (2) not lose sight of a topic, (3) clarify difficult points in stages. Conclusions: Pair programming requires skill beyond software development skill. To be able to identify knowledge needs and then push such knowledge to or pull it from the partner successfully is one aspect of such skill. We characterize a number of its elements.
As software engineers, we all have our opinions about what works and what does not (or not so wel... more As software engineers, we all have our opinions about what works and what does not (or not so well), and we share stories of practice and experience that are eventually distilled into cultural knowledge and received wisdom. The trouble is that “what everyone knows” is often wrong, and although we are continually collecting information, we may not be assessing and integrating that information critically, or even giving ourselves the wherewithal to do so.
Advocates of software design patterns claim that using design patterns improves communication bet... more Advocates of software design patterns claim that using design patterns improves communication between software developers. The controlled experiment that we describe in this report tests the hypotheses that software maintainers of well-structured, well-documented software containing de- sign patterns can make changes (1) faster and (2) with less errors if the use of patterns is explicitly documented in the software. The
Proceedings - International Conference on Software Engineering, 2013
ABSTRACT The classical definition of pair programming (PP) describes it via two obvious roles: dr... more ABSTRACT 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.
Proceedings of WCRE '96: 4rd Working Conference on Reverse Engineering, 1996
... deleg.' shows precision values that would result if Paradigm Plus were able to d... more ... deleg.' shows precision values that would result if Paradigm Plus were able to detect all simple call delegations and our pattern rules contained checks for them, making most ... We conclude that the Pat system is a fast and simple way to recover design information from source ...
Page 1. SKaMPI: A Detailed, Accurate MPI Benchmark Ralf Reussner ... de Abstract. SKaMPI is a ben... more Page 1. SKaMPI: A Detailed, Accurate MPI Benchmark Ralf Reussner ... de Abstract. SKaMPI is a benchmark for MPI implementations. Its pur ...
ABSTRACT Context Root-cause analysis is a data-driven technique for developing software process i... more ABSTRACT Context Root-cause analysis is a data-driven technique for developing software process improvements in mature software organizations. The search for individual process correlates of high defect densities, which we call defect insertion circumstance analysis (DICA), is potentially both effective and cost-efficient as one approach to be used when attempting a general defect root cause analysis. In DICA, data from existing repositories (version archive, bug tracker) is evaluated largely automatically in order to determine conditions (such as the people, roles, components, or time-periods involved) that correlate with higher-than-normal defect insertion frequencies. Nevertheless, no reports of industrial use of DICA have been published. Objective Determine the reasons why DICA is not used more often by practitioners. Method We use a single-case, typical-case, revelatory-type case study to evaluate in parallel the importance of six plausible reasons (R1 to R6). The case is based on 11 years of repository data from a small but mature software company building a product in the high-end content management system domain and describes a four person-months effort to make use of these data. Results While DICA required non-negligible effort (R3) and some degree of inventiveness (R2), the most relevant roadblock was insufficient reliability of the results (R6) combined with the difficulty of assessing this reliability (R5). We identify three difficulties that led to this outcome. Conclusion Current repository mining methods are too immature for successful DICA. Gradual improvements are unlikely to help; different principles of operation will be required. Even with such different techniques, issues with input data quality may continue to make good results difficult-to-have.
Proceedings of the 8th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement - ESEM '14, 2014
ABSTRACT Context: General knowledge transfer is often considered a valuable effect or side-effect... more ABSTRACT Context: General knowledge transfer is often considered a valuable effect or side-effect of pair programming, but even more important is its role for the success of the pair programming session itself: The partners often need to explain an idea to carry the process forward. Goal: Understand the mechanisms at work when knowledge is transferred during a pair programming session; provide practical advice for constructive behavior. Method: Qualitative data analysis of recordings of actual industrial pair programming sessions. Results: Some pairs are much more efficient in their knowledge transfer than others. These pairs manage to (1) not attempt to explain multiple things at once, (2) not lose sight of a topic, (3) clarify difficult points in stages. Conclusions: Pair programming requires skill beyond software development skill. To be able to identify knowledge needs and then push such knowledge to or pull it from the partner successfully is one aspect of such skill. We characterize a number of its elements.
As software engineers, we all have our opinions about what works and what does not (or not so wel... more As software engineers, we all have our opinions about what works and what does not (or not so well), and we share stories of practice and experience that are eventually distilled into cultural knowledge and received wisdom. The trouble is that “what everyone knows” is often wrong, and although we are continually collecting information, we may not be assessing and integrating that information critically, or even giving ourselves the wherewithal to do so.
Advocates of software design patterns claim that using design patterns improves communication bet... more Advocates of software design patterns claim that using design patterns improves communication between software developers. The controlled experiment that we describe in this report tests the hypotheses that software maintainers of well-structured, well-documented software containing de- sign patterns can make changes (1) faster and (2) with less errors if the use of patterns is explicitly documented in the software. The
Proceedings - International Conference on Software Engineering, 2013
ABSTRACT The classical definition of pair programming (PP) describes it via two obvious roles: dr... more ABSTRACT 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.
Uploads
Papers by Lutz Prechelt