Software quality assessments are critical in orga- nizations where the software has been produced... more Software quality assessments are critical in orga- nizations where the software has been produced by external vendors, or when the development and maintenance of a software product has been outsourced to external parties. These assess- ments are typically challenging because is not always possible to access the original developers (or sometimes is not even allowed), and in rare cases suppliers keep an account of the costs associated to code changes or defect fixes. In those situations, one is left with the artifacts (e.g., database, source code, and documentation) as the only sources of evidence for performing such evaluations. A major challenge is also to provide fact-based conclusions for supporting decision-making, instead of subjective interpretations based on expert assessments (an approach still very predominant in mainstream industrial practice). This paper describes an instance of a software quality evaluation process performed for an international logistics company, which combined: benchmark- based metrics threshold analysis, software visualization, and expert assessment. An interview was carried out afterwards with a member from the business division of the company, to assess the usefulness of the methodology and corresponding findings, and to explore avenues for future improvement.
ABSTRACT Context: Code smells are assumed to indicate bad design that leads to less maintainable ... more ABSTRACT Context: Code smells are assumed to indicate bad design that leads to less maintainable code. However, this assumption has not been investigated in controlled studies with professional software developers. Aim: This paper investigates the relationship between code smells and maintenance effort. Method: Six developers were hired to perform three maintenance tasks each on four functionally equivalent Java systems originally implemented by different companies. Each developer spent three to four weeks. In total, they modified 298 Java files in the four systems. An Eclipse IDE plug-in measured the exact amount of time a developer spent maintaining each file. Regression analysis was used to explain the effort using file properties, including the number of smells. Result: None of the 12 investigated smells was significantly associated with increased effort after we adjusted for file size and the number of changes; Refused Bequest was significantly associated with decreased effort. File size and the number of changes explained almost all of the modeled variation in effort. Conclusion: The effects of the 12 smells on maintenance effort were limited. To reduce maintenance effort, a focus on reducing code size and the work practices that limit the number of changes may be more beneficial than refactoring code smells.
2010 43rd Hawaii International Conference on System Sciences, 2010
As agile software development principles and methods are being adopted by large software product ... more As agile software development principles and methods are being adopted by large software product organizations it is important to understand the role of software entropy. That is, how the maintainability of a system may degrade over time due to continuous change. This may on one side affect the ability to act agile in planning and development. On the other side, an agile process may affect growth of entropy. We report from a case study of a successful software product line organization that has adopted the agile development method Evo, showing how agility and entropy are negatively related. We conclude this study by suggesting a two-step approach to manage entropy while maintaining process agility. First, the system needs to be restructured to establish a level of manageable entropy, and then, that the agile process must be complemented with continuous semiautomated quality monitoring and refactoring support.
2009 IEEE International Conference on Software Maintenance, 2009
Software entropy is a phenomenon where repeated changes gradually degrade the structure of the sy... more Software entropy is a phenomenon where repeated changes gradually degrade the structure of the system, making it hard to understand and maintain. This phenomenon imposes challenges for organizations that have moved to agile methods from other processes, despite agile's focus on adaptability and responsiveness to change. We have investigated this issue through an industrial case study, and reviewed the literature addressing software entropy, focusing on the detection of "code smells" and their treatment by refactoring. We found that in order to remain agile despite of software entropy, developers need better support for understanding, planning and testing the impact of changes. However, it is exactly work on refactoring decision support and task complexity analysis that is lacking in literature. Based on our findings, we discuss strategies for dealing with entropy in this context and present avenues for future research.
The present study explores potential usability gaps when users switch from a familiar to an unfam... more The present study explores potential usability gaps when users switch from a familiar to an unfamiliar mobile phone interface. A within-subject experiment was performed in which nine users familiar with Sony-Ericsson T630 and nine familiar with Nokia 7250 performed tasks on both phones. On average, test subjects spent more time on finishing tasks with an unfamiliar phone than with a familiar one. For two of the four tasks, there was a significant difference in completion time between the first-time Nokia users and the first-time Sony-Ericsson users. The tasks of adding a contact to the address book and sending an SMS to a contact in the address book were performed more quickly by new Nokia users than by new Sony-Ericsson users. The subjective difficulty ranking also showed that first-time Nokia users found the new phone easier to use than first-time Sony-Ericsson users did. Hierarchical Task Analysis is used as a potential explanation, and three other theories that relate to these findings are presented: mental models, habit errors, and emotional attachment.
Code smells are archetypes of design shortcomings in the code that can potentially cause problems... more Code smells are archetypes of design shortcomings in the code that can potentially cause problems during maintenance. One known approach for detecting code smells is via detection rules: a combination of different object-oriented metrics with pre-defined threshold values. The usage of inadequate thresholds when using this approach could lead to either having too few observations (too many false negatives) or too many observations (too many false positives). Furthermore, without a clear methodology for deriving thresholds, one is left with those suggested in literature (or by the tool vendors), which may not necessarily be suitable to the context of analysis. In this paper, we propose a data-driven (i.e., benchmark-based) method to derive threshold values for code metrics, which can be used for implementing detection rules for code smells. Our method is transparent, repeatable and enables the extraction of thresholds that respect the statistical properties of the metric in question (such as scale and distribution). Thus, our approach enables the calibration of code smell detection rules by selecting relevant systems as benchmark data. To illustrate our approach, we generated a benchmark dataset based on 74 systems of the Qualitas Corpus, and extracted the thresholds for five smell detection rules.
20th Working Conference on Reverse Engineering (WCRE 2013)
Code smells are a well-known metaphor to describe symptoms of code decay or other issues with cod... more Code smells are a well-known metaphor to describe symptoms of code decay or other issues with code quality which can lead to a variety of maintenance problems. Even though code smell detection and removal has been well-researched over the last decade, it remains open to debate whether or not code smells should be considered meaningful conceptualizations of code quality issues from the developer's perspective. To some extend, this question applies as well to the results provided by current code smell detection tools. Are code smells really important for developers? If they are not, is this due to the lack of relevance of the underlying concepts, due to the lack of awareness about code smells on the developers' side, or due to the lack of appropriate tools for code smell analysis or removal? In order to align and direct research efforts to address actual needs and problems of professional developers, we need to better understand the knowledge about, and interest in code smells, together with their perceived criticality. This paper reports on the results obtained from an exploratory survey involving 85 professional software developers.
Context: Code smells are indicators of poor coding and design choices that can cause problems dur... more Context: Code smells are indicators of poor coding and design choices that can cause problems during software maintenance and evolution.
ICSE '13 Proceedings of the 2013 International Conference on Software Engineering
Code smells are indicators of issues with source code quality that may hinder evolution. While pr... more Code smells are indicators of issues with source code quality that may hinder evolution. While previous studies mainly focused on the effects of individual code smells on maintainability, we conjecture that not only the individual code smells but also the interactions between code smells affect maintenance. We empirically investigate the interactions amongst 12 code smells and analyze how those interactions relate to maintenance problems. Professional developers were hired for a period of four weeks to implement change requests on four medium-sized Java systems with known smells. On a daily basis, we recorded what specific problems they faced and which artifacts were associated with them. Code smells were automatically detected in the pre-maintenance versions of the systems and analyzed using Principal Component Analysis (PCA) to identify patterns of co-located code smells. Analysis of these factors with the observed maintenance problems revealed how smells that were co-located in the same artifact interacted with each other, and affected maintainability. Moreover, we found that code smell interactions occurred across coupled artifacts, with comparable negative effects as same-artifact co-location. We argue that future studies into the effects of code smells on maintainability should integrate dependency analysis in their process so that they can obtain a more complete understanding by including such coupled interactions.
Code smells are indicators of deeper design problems that may cause difficulties in the evolution... more Code smells are indicators of deeper design problems that may cause difficulties in the evolution of a software system. This paper investigates the capabil- ity of twelve code smells to reflect actual maintenance problems. Four medium-sized systems with equivalent functionality but dissimilar design were examined for code smells. Three change requests were implemented on the systems by six software de- velopers, each of them working for up to four weeks. During that period, we recorded problems faced by developers and the associated Java files on a daily basis. We developed a binary logistic regression model, with “problematic file” as the depen- dent variable. Twelve code smells, file size, and churn constituted the independent variables. We found that violation of the Interface Segregation Principle (a.k.a. ISP violation) displayed the strongest connection with maintenance problems. Analysis of the nature of the problems, as reported by the developers in daily interviews and think-aloud sessions, strengthened our view about the relevance of this code smell. We observed, for example, that severe instances of problems relating to change propagation were associated with ISP violation. Based on our results, we recommend that code with ISP violation should be considered potentially problematic and be prioritized for refactoring.
Context: Code smells are manifestations of design flaws that can degrade code maintainability. So... more Context: Code smells are manifestations of design flaws that can degrade code maintainability. So far, no research has investigated if these indicators are useful for conducting system-level maintainability evaluations. Aim: The research in this paper investigates the potential of code smells to reflect system-level indicators of maintainability. Method: We evaluated four medium-sized Java systems using code smells and compared the results against previous evaluations on the same systems based on expert judgment and the Chidamber and Kemerer suite of metrics. The systems were maintained over a period of up to 4 weeks. During maintenance, effort (person-hours) and number of defects were measured to validate the different evaluation approaches. Results:
Most code smells are strongly influenced by size; consequently code smells are not good indicators for comparing the maintainability of systems differing greatly in size. Also, from the comparison of the different evaluation approaches, expert judgment was found as the most accurate and flexible since it considered effects due to the system's size and complexity and could adapt to different maintenance scenarios. Conclusion: Code smell approaches show promise as indicators of the need for maintenance in a way that other purely metric-based approaches lack.
Context: Code smells are assumed to indicate bad design that leads to less maintainable code. How... more Context: Code smells are assumed to indicate bad design that leads to less maintainable code. However, this assumption has not been investigated in controlled studies with professional software developers. Aim: This paper investigates the relationship between code smells and maintenance effort. Method: Six developers were hired to perform three maintenance tasks each on four functionally equivalent Java systems originally implemented by different companies. Each developer spent three to four weeks. In total, they modified 298 Java files in the four systems. An Eclipse IDE plug-in measured the exact amount of time a developer spent maintaining each file. Regression analysis was used to explain the effort using file properties, including the number of smells. Results: None of the 12 investigated smells was significantly associated with increased effort after we adjusted for file size and the number of changes; Refused Bequest was significantly associated with decreased effort. File size and the number of changes explained almost all of the modeled variation in effort. Conclusion: The effects of the 12 smells on maintenance effort were limited. To reduce maintenance effort, a focus on reducing code size and the work practices that limit the number of changes may be more beneficial than refactoring code smells.
Proceedings of the 28th IEEE International Conference on Software Maintenance, Sep 2012
Code smells are manifestations of design flaws that can degrade code maintainability. As such, th... more Code smells are manifestations of design flaws that can degrade code maintainability. As such, the existence of code smells seems an ideal indicator for maintainability assessments. However, to achieve comprehensive and accurate evaluations based on code smells, we need to know how well they reflect factors affecting maintainability. After identifying which maintainability factors are reflected by code smells and which not, we can use complementary means to assess the factors that are not addressed by smells. This paper reports on an empirical study that investigates the extent to which code smells reflect factors affecting maintainability that have been identified as important by programmers. We consider two sources for our analysis: (1) expert-based maintainability assessments of four Java systems before they entered a maintenance project, and (2) observations and interviews with professional developers who maintained these systems during 14 working days and implemented a number of change requests.
Proceedings of the 2010 43rd Hawaii International Conference on System Sciences, 2010
As agile software development principles and methods are being adopted by large software product ... more As agile software development principles and methods are being adopted by large software product organizations it is important to understand the role of software entropy. That is, how the maintainability of a system may degrade over time due to continuous change. This may on one side affect the ability to act agile in planning and development. On the other side, an agile process may affect growth of entropy. We report from a case study of a successful software product line organization that has adopted the agile development method Evo, showing how agility and entropy are negatively related. We conclude this study by suggesting a two-step approach to manage entropy while maintaining process agility. First, the system needs to be restructured to establish a level of manageable entropy, and then, that the agile process must be complemented with continuous semi-automated quality monitoring and refactoring support.
Proceedings of IEEE International Conference on Software Maintenance, 2009 (ICSM 09), 2009
Software entropy is a phenomenon where repeated changes gradually degrade the structure of the sy... more Software entropy is a phenomenon where repeated changes gradually degrade the structure of the system, making it hard to understand and maintain. This phenomenon imposes challenges for organizations that have moved to agile methods from other processes, despite agile's focus on adaptability and responsiveness to change. We have investigated this issue through an industrial case study, and reviewed the literature on addressing software entropy, focussing on the detection of ldquocode smellsrdquo and their treatment by refactoring. We found that in order to remain agile despite of software entropy, developers need better support for understanding, planning and testing the impact of changes. However, it is exactly work on refactoring decision support and task complexity analysis that is lacking in literature. Based on our findings, we discuss strategies for dealing with entropy in this context and present avenues for future research.
Many important phenomena within software engineering are difficult to define and measure. A good ... more Many important phenomena within software engineering are difficult to define and measure. A good example is software maintainability, which has been the subject of considerable research and is believed to be a critical determinant of total software costs. Yet, there is no common agreement on how to describe and measure software maintainability in a concrete setting. We propose using concept mapping, a well-grounded method used in social research, to operationalize this concept according to a given goal and perspective. We apply this method to describe four systems that were developed as part of an industrial multiple-case study. The outcome is a conceptual map that displays an arrangement of maintainability constructs, their interrelations and corresponding measures. Our experience is that concept mapping (1) provides a structured way of combining static code analysis and expert judgment; (2) helps tailoring the choice of measures to a particular system context; and (3) supports the mapping between software measures and aspects of software maintainability. As such, it represents a strong addition to existing frameworks for evaluating quality such as ISO/IEC 9126 and GQM, and tools for static measurement of software code. Overall, we find that concept mapping provides a systematic, structured and repeatable method for developing constructs and measures of the phenomenon of interest, and we deem it useful for defining constructs and measures of other aspects of software engineering, in addition to maintainability.
BCS-HCI '07 Proceedings of the 21st British HCI Group Annual Conference on People and Computers, 2007
The present study explores potential usability gaps when users switch from a familiar to an unfam... more The present study explores potential usability gaps when users switch from a familiar to an unfamiliar mobile phone interface. A within-subject experiment was performed in which nine users familiar with Sony-Ericsson T630 and nine familiar with Nokia 7250 performed tasks on both phones. On average, test subjects spent more time on finishing tasks with an unfamiliar phone than with a familiar one. For two of the four tasks, there was a significant difference in completion time between the first-time Nokia users and the first-time Sony-Ericsson users. The tasks of adding a contact to the address book and sending an SMS to a contact in the address book were performed more quickly by new Nokia users than by new Sony-Ericsson users. The subjective difficulty ranking also showed that first-time Nokia users found the new phone easier to use than first-time Sony-Ericsson users did. Hierarchical Task Analysis is used as a potential explanation, and three other theories that relate to these findings are presented: mental models, habit errors, and emotional attachment.
This paper presents the results of a case study examining prototyping as a method in re-designing... more This paper presents the results of a case study examining prototyping as a method in re-designing a user interface (UI). In the case presented, a web-based room booking was re-designed. Running on a university web site, the existing system has caused much critique amongst its users. Their expectations for a new UI were increased ease of use, less effort required, and less time consumed. We prototyped a new UI using Visio and tested it with a small number of experienced and novice users. Our results partly favor the existing system and partly the new one. To our surprise, experienced users performed relatively poorer with the new UI considering their critique of the existing one. We found paper prototyping to be an efficient method to gain user feedback on usability issues and that a low-fidelity prototype does not automatically mean low-effort testing. We observed that visible-state UI elements can be demanding to test through paper prototyping.
Software quality assessments are critical in orga- nizations where the software has been produced... more Software quality assessments are critical in orga- nizations where the software has been produced by external vendors, or when the development and maintenance of a software product has been outsourced to external parties. These assess- ments are typically challenging because is not always possible to access the original developers (or sometimes is not even allowed), and in rare cases suppliers keep an account of the costs associated to code changes or defect fixes. In those situations, one is left with the artifacts (e.g., database, source code, and documentation) as the only sources of evidence for performing such evaluations. A major challenge is also to provide fact-based conclusions for supporting decision-making, instead of subjective interpretations based on expert assessments (an approach still very predominant in mainstream industrial practice). This paper describes an instance of a software quality evaluation process performed for an international logistics company, which combined: benchmark- based metrics threshold analysis, software visualization, and expert assessment. An interview was carried out afterwards with a member from the business division of the company, to assess the usefulness of the methodology and corresponding findings, and to explore avenues for future improvement.
ABSTRACT Context: Code smells are assumed to indicate bad design that leads to less maintainable ... more ABSTRACT Context: Code smells are assumed to indicate bad design that leads to less maintainable code. However, this assumption has not been investigated in controlled studies with professional software developers. Aim: This paper investigates the relationship between code smells and maintenance effort. Method: Six developers were hired to perform three maintenance tasks each on four functionally equivalent Java systems originally implemented by different companies. Each developer spent three to four weeks. In total, they modified 298 Java files in the four systems. An Eclipse IDE plug-in measured the exact amount of time a developer spent maintaining each file. Regression analysis was used to explain the effort using file properties, including the number of smells. Result: None of the 12 investigated smells was significantly associated with increased effort after we adjusted for file size and the number of changes; Refused Bequest was significantly associated with decreased effort. File size and the number of changes explained almost all of the modeled variation in effort. Conclusion: The effects of the 12 smells on maintenance effort were limited. To reduce maintenance effort, a focus on reducing code size and the work practices that limit the number of changes may be more beneficial than refactoring code smells.
2010 43rd Hawaii International Conference on System Sciences, 2010
As agile software development principles and methods are being adopted by large software product ... more As agile software development principles and methods are being adopted by large software product organizations it is important to understand the role of software entropy. That is, how the maintainability of a system may degrade over time due to continuous change. This may on one side affect the ability to act agile in planning and development. On the other side, an agile process may affect growth of entropy. We report from a case study of a successful software product line organization that has adopted the agile development method Evo, showing how agility and entropy are negatively related. We conclude this study by suggesting a two-step approach to manage entropy while maintaining process agility. First, the system needs to be restructured to establish a level of manageable entropy, and then, that the agile process must be complemented with continuous semiautomated quality monitoring and refactoring support.
2009 IEEE International Conference on Software Maintenance, 2009
Software entropy is a phenomenon where repeated changes gradually degrade the structure of the sy... more Software entropy is a phenomenon where repeated changes gradually degrade the structure of the system, making it hard to understand and maintain. This phenomenon imposes challenges for organizations that have moved to agile methods from other processes, despite agile's focus on adaptability and responsiveness to change. We have investigated this issue through an industrial case study, and reviewed the literature addressing software entropy, focusing on the detection of "code smells" and their treatment by refactoring. We found that in order to remain agile despite of software entropy, developers need better support for understanding, planning and testing the impact of changes. However, it is exactly work on refactoring decision support and task complexity analysis that is lacking in literature. Based on our findings, we discuss strategies for dealing with entropy in this context and present avenues for future research.
The present study explores potential usability gaps when users switch from a familiar to an unfam... more The present study explores potential usability gaps when users switch from a familiar to an unfamiliar mobile phone interface. A within-subject experiment was performed in which nine users familiar with Sony-Ericsson T630 and nine familiar with Nokia 7250 performed tasks on both phones. On average, test subjects spent more time on finishing tasks with an unfamiliar phone than with a familiar one. For two of the four tasks, there was a significant difference in completion time between the first-time Nokia users and the first-time Sony-Ericsson users. The tasks of adding a contact to the address book and sending an SMS to a contact in the address book were performed more quickly by new Nokia users than by new Sony-Ericsson users. The subjective difficulty ranking also showed that first-time Nokia users found the new phone easier to use than first-time Sony-Ericsson users did. Hierarchical Task Analysis is used as a potential explanation, and three other theories that relate to these findings are presented: mental models, habit errors, and emotional attachment.
Code smells are archetypes of design shortcomings in the code that can potentially cause problems... more Code smells are archetypes of design shortcomings in the code that can potentially cause problems during maintenance. One known approach for detecting code smells is via detection rules: a combination of different object-oriented metrics with pre-defined threshold values. The usage of inadequate thresholds when using this approach could lead to either having too few observations (too many false negatives) or too many observations (too many false positives). Furthermore, without a clear methodology for deriving thresholds, one is left with those suggested in literature (or by the tool vendors), which may not necessarily be suitable to the context of analysis. In this paper, we propose a data-driven (i.e., benchmark-based) method to derive threshold values for code metrics, which can be used for implementing detection rules for code smells. Our method is transparent, repeatable and enables the extraction of thresholds that respect the statistical properties of the metric in question (such as scale and distribution). Thus, our approach enables the calibration of code smell detection rules by selecting relevant systems as benchmark data. To illustrate our approach, we generated a benchmark dataset based on 74 systems of the Qualitas Corpus, and extracted the thresholds for five smell detection rules.
20th Working Conference on Reverse Engineering (WCRE 2013)
Code smells are a well-known metaphor to describe symptoms of code decay or other issues with cod... more Code smells are a well-known metaphor to describe symptoms of code decay or other issues with code quality which can lead to a variety of maintenance problems. Even though code smell detection and removal has been well-researched over the last decade, it remains open to debate whether or not code smells should be considered meaningful conceptualizations of code quality issues from the developer's perspective. To some extend, this question applies as well to the results provided by current code smell detection tools. Are code smells really important for developers? If they are not, is this due to the lack of relevance of the underlying concepts, due to the lack of awareness about code smells on the developers' side, or due to the lack of appropriate tools for code smell analysis or removal? In order to align and direct research efforts to address actual needs and problems of professional developers, we need to better understand the knowledge about, and interest in code smells, together with their perceived criticality. This paper reports on the results obtained from an exploratory survey involving 85 professional software developers.
Context: Code smells are indicators of poor coding and design choices that can cause problems dur... more Context: Code smells are indicators of poor coding and design choices that can cause problems during software maintenance and evolution.
ICSE '13 Proceedings of the 2013 International Conference on Software Engineering
Code smells are indicators of issues with source code quality that may hinder evolution. While pr... more Code smells are indicators of issues with source code quality that may hinder evolution. While previous studies mainly focused on the effects of individual code smells on maintainability, we conjecture that not only the individual code smells but also the interactions between code smells affect maintenance. We empirically investigate the interactions amongst 12 code smells and analyze how those interactions relate to maintenance problems. Professional developers were hired for a period of four weeks to implement change requests on four medium-sized Java systems with known smells. On a daily basis, we recorded what specific problems they faced and which artifacts were associated with them. Code smells were automatically detected in the pre-maintenance versions of the systems and analyzed using Principal Component Analysis (PCA) to identify patterns of co-located code smells. Analysis of these factors with the observed maintenance problems revealed how smells that were co-located in the same artifact interacted with each other, and affected maintainability. Moreover, we found that code smell interactions occurred across coupled artifacts, with comparable negative effects as same-artifact co-location. We argue that future studies into the effects of code smells on maintainability should integrate dependency analysis in their process so that they can obtain a more complete understanding by including such coupled interactions.
Code smells are indicators of deeper design problems that may cause difficulties in the evolution... more Code smells are indicators of deeper design problems that may cause difficulties in the evolution of a software system. This paper investigates the capabil- ity of twelve code smells to reflect actual maintenance problems. Four medium-sized systems with equivalent functionality but dissimilar design were examined for code smells. Three change requests were implemented on the systems by six software de- velopers, each of them working for up to four weeks. During that period, we recorded problems faced by developers and the associated Java files on a daily basis. We developed a binary logistic regression model, with “problematic file” as the depen- dent variable. Twelve code smells, file size, and churn constituted the independent variables. We found that violation of the Interface Segregation Principle (a.k.a. ISP violation) displayed the strongest connection with maintenance problems. Analysis of the nature of the problems, as reported by the developers in daily interviews and think-aloud sessions, strengthened our view about the relevance of this code smell. We observed, for example, that severe instances of problems relating to change propagation were associated with ISP violation. Based on our results, we recommend that code with ISP violation should be considered potentially problematic and be prioritized for refactoring.
Context: Code smells are manifestations of design flaws that can degrade code maintainability. So... more Context: Code smells are manifestations of design flaws that can degrade code maintainability. So far, no research has investigated if these indicators are useful for conducting system-level maintainability evaluations. Aim: The research in this paper investigates the potential of code smells to reflect system-level indicators of maintainability. Method: We evaluated four medium-sized Java systems using code smells and compared the results against previous evaluations on the same systems based on expert judgment and the Chidamber and Kemerer suite of metrics. The systems were maintained over a period of up to 4 weeks. During maintenance, effort (person-hours) and number of defects were measured to validate the different evaluation approaches. Results:
Most code smells are strongly influenced by size; consequently code smells are not good indicators for comparing the maintainability of systems differing greatly in size. Also, from the comparison of the different evaluation approaches, expert judgment was found as the most accurate and flexible since it considered effects due to the system's size and complexity and could adapt to different maintenance scenarios. Conclusion: Code smell approaches show promise as indicators of the need for maintenance in a way that other purely metric-based approaches lack.
Context: Code smells are assumed to indicate bad design that leads to less maintainable code. How... more Context: Code smells are assumed to indicate bad design that leads to less maintainable code. However, this assumption has not been investigated in controlled studies with professional software developers. Aim: This paper investigates the relationship between code smells and maintenance effort. Method: Six developers were hired to perform three maintenance tasks each on four functionally equivalent Java systems originally implemented by different companies. Each developer spent three to four weeks. In total, they modified 298 Java files in the four systems. An Eclipse IDE plug-in measured the exact amount of time a developer spent maintaining each file. Regression analysis was used to explain the effort using file properties, including the number of smells. Results: None of the 12 investigated smells was significantly associated with increased effort after we adjusted for file size and the number of changes; Refused Bequest was significantly associated with decreased effort. File size and the number of changes explained almost all of the modeled variation in effort. Conclusion: The effects of the 12 smells on maintenance effort were limited. To reduce maintenance effort, a focus on reducing code size and the work practices that limit the number of changes may be more beneficial than refactoring code smells.
Proceedings of the 28th IEEE International Conference on Software Maintenance, Sep 2012
Code smells are manifestations of design flaws that can degrade code maintainability. As such, th... more Code smells are manifestations of design flaws that can degrade code maintainability. As such, the existence of code smells seems an ideal indicator for maintainability assessments. However, to achieve comprehensive and accurate evaluations based on code smells, we need to know how well they reflect factors affecting maintainability. After identifying which maintainability factors are reflected by code smells and which not, we can use complementary means to assess the factors that are not addressed by smells. This paper reports on an empirical study that investigates the extent to which code smells reflect factors affecting maintainability that have been identified as important by programmers. We consider two sources for our analysis: (1) expert-based maintainability assessments of four Java systems before they entered a maintenance project, and (2) observations and interviews with professional developers who maintained these systems during 14 working days and implemented a number of change requests.
Proceedings of the 2010 43rd Hawaii International Conference on System Sciences, 2010
As agile software development principles and methods are being adopted by large software product ... more As agile software development principles and methods are being adopted by large software product organizations it is important to understand the role of software entropy. That is, how the maintainability of a system may degrade over time due to continuous change. This may on one side affect the ability to act agile in planning and development. On the other side, an agile process may affect growth of entropy. We report from a case study of a successful software product line organization that has adopted the agile development method Evo, showing how agility and entropy are negatively related. We conclude this study by suggesting a two-step approach to manage entropy while maintaining process agility. First, the system needs to be restructured to establish a level of manageable entropy, and then, that the agile process must be complemented with continuous semi-automated quality monitoring and refactoring support.
Proceedings of IEEE International Conference on Software Maintenance, 2009 (ICSM 09), 2009
Software entropy is a phenomenon where repeated changes gradually degrade the structure of the sy... more Software entropy is a phenomenon where repeated changes gradually degrade the structure of the system, making it hard to understand and maintain. This phenomenon imposes challenges for organizations that have moved to agile methods from other processes, despite agile's focus on adaptability and responsiveness to change. We have investigated this issue through an industrial case study, and reviewed the literature on addressing software entropy, focussing on the detection of ldquocode smellsrdquo and their treatment by refactoring. We found that in order to remain agile despite of software entropy, developers need better support for understanding, planning and testing the impact of changes. However, it is exactly work on refactoring decision support and task complexity analysis that is lacking in literature. Based on our findings, we discuss strategies for dealing with entropy in this context and present avenues for future research.
Many important phenomena within software engineering are difficult to define and measure. A good ... more Many important phenomena within software engineering are difficult to define and measure. A good example is software maintainability, which has been the subject of considerable research and is believed to be a critical determinant of total software costs. Yet, there is no common agreement on how to describe and measure software maintainability in a concrete setting. We propose using concept mapping, a well-grounded method used in social research, to operationalize this concept according to a given goal and perspective. We apply this method to describe four systems that were developed as part of an industrial multiple-case study. The outcome is a conceptual map that displays an arrangement of maintainability constructs, their interrelations and corresponding measures. Our experience is that concept mapping (1) provides a structured way of combining static code analysis and expert judgment; (2) helps tailoring the choice of measures to a particular system context; and (3) supports the mapping between software measures and aspects of software maintainability. As such, it represents a strong addition to existing frameworks for evaluating quality such as ISO/IEC 9126 and GQM, and tools for static measurement of software code. Overall, we find that concept mapping provides a systematic, structured and repeatable method for developing constructs and measures of the phenomenon of interest, and we deem it useful for defining constructs and measures of other aspects of software engineering, in addition to maintainability.
BCS-HCI '07 Proceedings of the 21st British HCI Group Annual Conference on People and Computers, 2007
The present study explores potential usability gaps when users switch from a familiar to an unfam... more The present study explores potential usability gaps when users switch from a familiar to an unfamiliar mobile phone interface. A within-subject experiment was performed in which nine users familiar with Sony-Ericsson T630 and nine familiar with Nokia 7250 performed tasks on both phones. On average, test subjects spent more time on finishing tasks with an unfamiliar phone than with a familiar one. For two of the four tasks, there was a significant difference in completion time between the first-time Nokia users and the first-time Sony-Ericsson users. The tasks of adding a contact to the address book and sending an SMS to a contact in the address book were performed more quickly by new Nokia users than by new Sony-Ericsson users. The subjective difficulty ranking also showed that first-time Nokia users found the new phone easier to use than first-time Sony-Ericsson users did. Hierarchical Task Analysis is used as a potential explanation, and three other theories that relate to these findings are presented: mental models, habit errors, and emotional attachment.
This paper presents the results of a case study examining prototyping as a method in re-designing... more This paper presents the results of a case study examining prototyping as a method in re-designing a user interface (UI). In the case presented, a web-based room booking was re-designed. Running on a university web site, the existing system has caused much critique amongst its users. Their expectations for a new UI were increased ease of use, less effort required, and less time consumed. We prototyped a new UI using Visio and tested it with a small number of experienced and novice users. Our results partly favor the existing system and partly the new one. To our surprise, experienced users performed relatively poorer with the new UI considering their critique of the existing one. We found paper prototyping to be an efficient method to gain user feedback on usability issues and that a low-fidelity prototype does not automatically mean low-effort testing. We observed that visible-state UI elements can be demanding to test through paper prototyping.
Uploads
Papers by Aiko Yamashita
Most code smells are strongly influenced by size; consequently code smells are not good indicators for comparing the maintainability of systems differing greatly in size. Also, from the comparison of the different evaluation approaches, expert judgment was found as the most accurate and flexible since it considered effects due to the system's size and complexity and could adapt to different maintenance scenarios. Conclusion: Code smell approaches show promise as indicators of the need for maintenance in a way that other purely metric-based approaches lack.
Most code smells are strongly influenced by size; consequently code smells are not good indicators for comparing the maintainability of systems differing greatly in size. Also, from the comparison of the different evaluation approaches, expert judgment was found as the most accurate and flexible since it considered effects due to the system's size and complexity and could adapt to different maintenance scenarios. Conclusion: Code smell approaches show promise as indicators of the need for maintenance in a way that other purely metric-based approaches lack.