2015 IEEE International Conference on Software Maintenance and Evolution (ICSME), 2015
Software engineering research now considers that no system is an island, but it is part of an eco... more Software engineering research now considers that no system is an island, but it is part of an ecosystem involving other systems, developers, users, hardware, . . . When one system (e.g., a framework) evolves, its clients often need to adapt. Client developers might need to adapt to functionalities, client systems might need to be adapted to a new API, client users might need to adapt to a new User Interface. The consequences of such changes are yet unclear, what proportion of the ecosystem might be expected to react, how long might it take for a change to diffuse in the ecosystem, do all clients react in the same way? This paper reports on an exploratory study aimed at observing API evolution and its impact on a large-scale software ecosystem, Pharo, which has about 3,600 distinct systems, more than 2,800 contributors, and six years of evolution. We analyze 118 API changes and answer research questions regarding the magnitude, duration, extension, and consistency of such changes in the ecosystem. The results of this study help to characterize the impact of API evolution in large software ecosystems, and provide the basis to better understand how such impact can be alleviated.
Software development practice still relies on the notion that programming is equivalent to editin... more Software development practice still relies on the notion that programming is equivalent to editing text. This view is also supported by mainstream versioning systems, such as CVS and SubVersion, which are excellent at versioning text files. We argue that programming = text editing may have been true years ago, but nowadays we construct complex systems by changing them piecemeal. However, despite recent advances which explicitly support change, such as refactorings and agile development methodologies, most development tools in use are ill-suited to deal with software change: they see a system as a collection of text files. This vision leads to code which is harder to understand since its history is not easily accessible, and harder to change since such a representation of code is against the inherently incremental nature of software development.
More than 90% of the cost of software is due to maintenance and evolution1. We claim that the com... more More than 90% of the cost of software is due to maintenance and evolution1. We claim that the commonly held vision of a software as a set of files, and its history as a set of versions does not accurately represent the phenomenon of software evolution: Software development is an incremental process more complex than simply writing lines of text.
Rumor has it that programmers write software. Indeed, any modern integrated development environme... more Rumor has it that programmers write software. Indeed, any modern integrated development environment (IDE) features numerous tools providing the means to write and browse textual representations of code artifacts. However, considering the complexity of current software systems, words other than writing are used, such as constructing, building, architecting, designing, etc. This "stepping away" from the notion that programming equals writing is supported by object-oriented languages, which promote reasoning around objects (mimicking real-world objects) sending each other messages. Our goal is to depart from IDEs as fancy text editors, towards an environment that eases the interaction and the crafting of objects without creating a barrier between a developer and his creation. We present Gaucho, a direct manipulation environment which allows one to freely create, place, and interact with object-oriented concepts and abstractions in a consistent and unconstrained way.
Proceedings of the 36th International Conference on Software Engineering - ICSE 2014, 2014
ABSTRACT When developers use Application Programming Interfaces (APIs), they often rely on docume... more ABSTRACT When developers use Application Programming Interfaces (APIs), they often rely on documentation to assist their tasks. In previous studies, we reported evidence indicating that static type systems acted as a form of implicit documentation, benefiting developer productivity. Such implicit documentation is easier to maintain, given it is enforced by the compiler, but previous experiments tested users without any explicit documentation. In this paper, we report on a controlled experiment and an exploratory study comparing the impact of using documentation and a static or dynamic type system on a development task. Results of our study both confirm previous findings and show that the benefits of static typing are strengthened with explicit documentation, but that this was not as strongly felt with dynamically typed languages.
2012 20th IEEE International Conference on Program Comprehension (ICPC), 2012
Static type systems play an essential role in contemporary programming languages. Despite their i... more Static type systems play an essential role in contemporary programming languages. Despite their importance, whether static type systems influence human software development capabilities remains an open question. One frequently mentioned argument for static type systems is that they improve the maintainability of software systems-an often used claim for which there is no empirical evidence. This paper describes an experiment which tests whether static type systems improve the maintainability of software systems. The results show rigorous empirical evidence that static type are indeed beneficial to these activities, except for fixing semantic errors.
Mainstream IDEs generally rely on the static structure of a software project to support browsing ... more Mainstream IDEs generally rely on the static structure of a software project to support browsing and navigation. Previous research has shown that other forms of information, such as evolution of the software artifacts, historical information capturing how previous developers have navigated the code, or runtime behavior of the application, can be much more useful than the static structure of the software to direct developers to parts of the code relevant to a taskat-hand. These different kinds of information, however, are not uniformly accessible from the IDE, so the developer may have to struggle with heterogeneous tools and visualizations to find the relevant artifacts. We propose HeatMaps, a simple but highly configurable technique to enrich the way an IDE displays the static structure of a software system with additional kinds of information. A HeatMap highlights software artifacts according to various metric values, such as bright red or pale blue, to indicate their potential de...
2013 10th Working Conference on Mining Software Repositories (MSR), 2013
ABSTRACT The expertise of a software developer is said to be a crucial factor for the development... more ABSTRACT The expertise of a software developer is said to be a crucial factor for the development time required to complete a task. Even if this hypothesis is intuitive, research has not yet quantified the effect of developer expertise on development time. A related problem is that the design space for expertise metrics is large; out of the various automated expertise metrics proposed, we do not know which metric most reliably captures expertise. What prevents a proper evaluation of expertise metrics and their relation with development time is the lack of data on development tasks, such as their precise duration. Fortunately, this data is starting to become available in the form of growing developer interaction repositories. We show that applying MSR techniques to these developer interaction repositories gives us the necessary tools to perform such an evaluation.
Proceedings of the 2013 International Workshop on Ecosystem Architectures - WEA 2013, 2013
ABSTRACT The natural distributed character of software ecosystems calls for a shared conceptualiz... more ABSTRACT The natural distributed character of software ecosystems calls for a shared conceptualization and language to describe their architecture and their evolution. In this regards, ontologies play a central role. In this paper: we argue in favor of such an approach by showing that there is succesful experience applying ontologies to the fields of software engineering and software architecture; show the issues arising in ecosystem evolution and the needs for higher levels of formalization of the description of such processes; finally, we present a roadmap to develop an ontology for this area.
Software evolution research is limited by the amount of information available to researchers: Cur... more Software evolution research is limited by the amount of information available to researchers: Current version con- trol tools do not store all the information generated by de- velopers. They do not record every intermediate version of the system issued, but only snapshots taken when a devel- oper commits source code into the repository. Additionally, most software evolution analysis tools are
Proceedings of the 10th ACM Symposium on Dynamic languages - DLS '14, 2014
Object-orientation relies on polymorphism to express behavioral variants. As opposed to tradition... more Object-orientation relies on polymorphism to express behavioral variants. As opposed to traditional procedural design, explicit typebased conditionals should be avoided. This message is conveyed in introductory material on object orientation, as well as in objectoriented reengineering patterns. Is this principle followed in practice? In other words, are type predicates actually used in objectoriented software, and if so, to which extent?
The analysis of the evolution of software systems is a useful source of information for a variety... more The analysis of the evolution of software systems is a useful source of information for a variety of activities, such as reverse engineering, maintenance, and predicting the future evolution of these systems. Current software evolution research is mainly based on the information contained in versioning systems such as CVS and SubVersion. But the evolutionary information contained therein is incomplete and of low quality, hence limiting the scope of evolution research. It is incomplete because the historical information is only recorded at the explicit request of the developers (a commit in the classical checkin/checkout model). It is of low quality because the file-based nature of versioning systems leads to a view of software as being a set of files. In this paper we present a novel approach to software evolution analysis which is based on the recording of all semantic changes performed on a system, such as refactorings. We describe our approach in detail, and demonstrate how it can be used to perform fine-grained software evolution analysis.
International Workshop on Principles of Software Evolution (IWPSE), 2005
Research in evolution goes on par with the use of versioning systems by developers of the case st... more Research in evolution goes on par with the use of versioning systems by developers of the case studies. There is a great diversity of versioning systems with advantages and disadvantages both from the technical as well as from the conceptual point of view. In this paper we analyze the currently used versioning systems from the point of view of a software evolution researcher. Thus we do not focus on whether a certain versioning system is technically better than another one, but rather on what kind of information it offers for software evolution research. We present a non-exhaustive list of dimensions that are important for performing research in software evolution, do a survey on the current main-stream versioning systems and discuss what is actually needed for future versioning systems to support both software evolution and the related research field.
2015 IEEE International Conference on Software Maintenance and Evolution (ICSME), 2015
Software engineering research now considers that no system is an island, but it is part of an eco... more Software engineering research now considers that no system is an island, but it is part of an ecosystem involving other systems, developers, users, hardware, . . . When one system (e.g., a framework) evolves, its clients often need to adapt. Client developers might need to adapt to functionalities, client systems might need to be adapted to a new API, client users might need to adapt to a new User Interface. The consequences of such changes are yet unclear, what proportion of the ecosystem might be expected to react, how long might it take for a change to diffuse in the ecosystem, do all clients react in the same way? This paper reports on an exploratory study aimed at observing API evolution and its impact on a large-scale software ecosystem, Pharo, which has about 3,600 distinct systems, more than 2,800 contributors, and six years of evolution. We analyze 118 API changes and answer research questions regarding the magnitude, duration, extension, and consistency of such changes in the ecosystem. The results of this study help to characterize the impact of API evolution in large software ecosystems, and provide the basis to better understand how such impact can be alleviated.
Software development practice still relies on the notion that programming is equivalent to editin... more Software development practice still relies on the notion that programming is equivalent to editing text. This view is also supported by mainstream versioning systems, such as CVS and SubVersion, which are excellent at versioning text files. We argue that programming = text editing may have been true years ago, but nowadays we construct complex systems by changing them piecemeal. However, despite recent advances which explicitly support change, such as refactorings and agile development methodologies, most development tools in use are ill-suited to deal with software change: they see a system as a collection of text files. This vision leads to code which is harder to understand since its history is not easily accessible, and harder to change since such a representation of code is against the inherently incremental nature of software development.
More than 90% of the cost of software is due to maintenance and evolution1. We claim that the com... more More than 90% of the cost of software is due to maintenance and evolution1. We claim that the commonly held vision of a software as a set of files, and its history as a set of versions does not accurately represent the phenomenon of software evolution: Software development is an incremental process more complex than simply writing lines of text.
Rumor has it that programmers write software. Indeed, any modern integrated development environme... more Rumor has it that programmers write software. Indeed, any modern integrated development environment (IDE) features numerous tools providing the means to write and browse textual representations of code artifacts. However, considering the complexity of current software systems, words other than writing are used, such as constructing, building, architecting, designing, etc. This "stepping away" from the notion that programming equals writing is supported by object-oriented languages, which promote reasoning around objects (mimicking real-world objects) sending each other messages. Our goal is to depart from IDEs as fancy text editors, towards an environment that eases the interaction and the crafting of objects without creating a barrier between a developer and his creation. We present Gaucho, a direct manipulation environment which allows one to freely create, place, and interact with object-oriented concepts and abstractions in a consistent and unconstrained way.
Proceedings of the 36th International Conference on Software Engineering - ICSE 2014, 2014
ABSTRACT When developers use Application Programming Interfaces (APIs), they often rely on docume... more ABSTRACT When developers use Application Programming Interfaces (APIs), they often rely on documentation to assist their tasks. In previous studies, we reported evidence indicating that static type systems acted as a form of implicit documentation, benefiting developer productivity. Such implicit documentation is easier to maintain, given it is enforced by the compiler, but previous experiments tested users without any explicit documentation. In this paper, we report on a controlled experiment and an exploratory study comparing the impact of using documentation and a static or dynamic type system on a development task. Results of our study both confirm previous findings and show that the benefits of static typing are strengthened with explicit documentation, but that this was not as strongly felt with dynamically typed languages.
2012 20th IEEE International Conference on Program Comprehension (ICPC), 2012
Static type systems play an essential role in contemporary programming languages. Despite their i... more Static type systems play an essential role in contemporary programming languages. Despite their importance, whether static type systems influence human software development capabilities remains an open question. One frequently mentioned argument for static type systems is that they improve the maintainability of software systems-an often used claim for which there is no empirical evidence. This paper describes an experiment which tests whether static type systems improve the maintainability of software systems. The results show rigorous empirical evidence that static type are indeed beneficial to these activities, except for fixing semantic errors.
Mainstream IDEs generally rely on the static structure of a software project to support browsing ... more Mainstream IDEs generally rely on the static structure of a software project to support browsing and navigation. Previous research has shown that other forms of information, such as evolution of the software artifacts, historical information capturing how previous developers have navigated the code, or runtime behavior of the application, can be much more useful than the static structure of the software to direct developers to parts of the code relevant to a taskat-hand. These different kinds of information, however, are not uniformly accessible from the IDE, so the developer may have to struggle with heterogeneous tools and visualizations to find the relevant artifacts. We propose HeatMaps, a simple but highly configurable technique to enrich the way an IDE displays the static structure of a software system with additional kinds of information. A HeatMap highlights software artifacts according to various metric values, such as bright red or pale blue, to indicate their potential de...
2013 10th Working Conference on Mining Software Repositories (MSR), 2013
ABSTRACT The expertise of a software developer is said to be a crucial factor for the development... more ABSTRACT The expertise of a software developer is said to be a crucial factor for the development time required to complete a task. Even if this hypothesis is intuitive, research has not yet quantified the effect of developer expertise on development time. A related problem is that the design space for expertise metrics is large; out of the various automated expertise metrics proposed, we do not know which metric most reliably captures expertise. What prevents a proper evaluation of expertise metrics and their relation with development time is the lack of data on development tasks, such as their precise duration. Fortunately, this data is starting to become available in the form of growing developer interaction repositories. We show that applying MSR techniques to these developer interaction repositories gives us the necessary tools to perform such an evaluation.
Proceedings of the 2013 International Workshop on Ecosystem Architectures - WEA 2013, 2013
ABSTRACT The natural distributed character of software ecosystems calls for a shared conceptualiz... more ABSTRACT The natural distributed character of software ecosystems calls for a shared conceptualization and language to describe their architecture and their evolution. In this regards, ontologies play a central role. In this paper: we argue in favor of such an approach by showing that there is succesful experience applying ontologies to the fields of software engineering and software architecture; show the issues arising in ecosystem evolution and the needs for higher levels of formalization of the description of such processes; finally, we present a roadmap to develop an ontology for this area.
Software evolution research is limited by the amount of information available to researchers: Cur... more Software evolution research is limited by the amount of information available to researchers: Current version con- trol tools do not store all the information generated by de- velopers. They do not record every intermediate version of the system issued, but only snapshots taken when a devel- oper commits source code into the repository. Additionally, most software evolution analysis tools are
Proceedings of the 10th ACM Symposium on Dynamic languages - DLS '14, 2014
Object-orientation relies on polymorphism to express behavioral variants. As opposed to tradition... more Object-orientation relies on polymorphism to express behavioral variants. As opposed to traditional procedural design, explicit typebased conditionals should be avoided. This message is conveyed in introductory material on object orientation, as well as in objectoriented reengineering patterns. Is this principle followed in practice? In other words, are type predicates actually used in objectoriented software, and if so, to which extent?
The analysis of the evolution of software systems is a useful source of information for a variety... more The analysis of the evolution of software systems is a useful source of information for a variety of activities, such as reverse engineering, maintenance, and predicting the future evolution of these systems. Current software evolution research is mainly based on the information contained in versioning systems such as CVS and SubVersion. But the evolutionary information contained therein is incomplete and of low quality, hence limiting the scope of evolution research. It is incomplete because the historical information is only recorded at the explicit request of the developers (a commit in the classical checkin/checkout model). It is of low quality because the file-based nature of versioning systems leads to a view of software as being a set of files. In this paper we present a novel approach to software evolution analysis which is based on the recording of all semantic changes performed on a system, such as refactorings. We describe our approach in detail, and demonstrate how it can be used to perform fine-grained software evolution analysis.
International Workshop on Principles of Software Evolution (IWPSE), 2005
Research in evolution goes on par with the use of versioning systems by developers of the case st... more Research in evolution goes on par with the use of versioning systems by developers of the case studies. There is a great diversity of versioning systems with advantages and disadvantages both from the technical as well as from the conceptual point of view. In this paper we analyze the currently used versioning systems from the point of view of a software evolution researcher. Thus we do not focus on whether a certain versioning system is technically better than another one, but rather on what kind of information it offers for software evolution research. We present a non-exhaustive list of dimensions that are important for performing research in software evolution, do a survey on the current main-stream versioning systems and discuss what is actually needed for future versioning systems to support both software evolution and the related research field.
Uploads
Papers by Romain Robbes