Skip to main content

Advertisement

SpringerLink
Log in

Perspectives on refactoring planning and practice: an empirical study

  • Published:
Empirical Software Engineering Aims and scope Submit manuscript

Abstract

Iterative development increasingly seeks to incorporate design modification and continuous refactoring in order to maintain code quality even in highly dynamic environments. However, there does not appear to be consensus on how to do this, especially because research results seem to be inconsistent. This paper presents an empirical study based upon an industry survey of refactoring practices and attitudes. The study explored differences in attitudes about refactoring among participants who played roles in software development, and how these different attitudes affected actual practice. The study found strong agreement among all roles about the importance of refactoring, and agreement about the negative effects upon agility of deferring refactoring. Nevertheless, the survey found that roles had different perspectives on the different kinds of tasks in an agile process. Accordingly, there was no universally agreed-upon strategy for how to plan to carry out refactoring. Analysis of the survey results has raised many interesting questions suggesting the need for a considerable amount of future research.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Log in via an institution

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Institutional subscriptions

Fig. 1
Fig. 2
Fig. 3

Similar content being viewed by others

References

  • Alshayeb M, Li W (2005) An empirical study of system design instability metric and design evolution in an agile software process. J Syst Softw 74(3):269–274

    Article  Google Scholar 

  • Beck K (2000) Extreme programming explained: embrace change. Addison-Wesley Professional

  • Begel A, Nagappan N (2007, September). Usage and perceptions of agile software development in an industrial context: An exploratory study. In Empirical Software Engineering and Measurement, 2007. ESEM 2007. First International Symposium on (pp 255–264). IEEE

  • Belady LA, Lehman MM (1976) A model of large program development. IBM Syst J 15(3):225–252

    Article  MATH  Google Scholar 

  • Bellomo S, Nord RL, Ozkaya I (2013, May). A study of enabling factors for rapid fielding combined practices to balance speed and stability. In Software Engineering (ICSE), 2013 35th International Conference on (pp 982–991). IEEE

  • Brasil MMA, da Silva TGN, de Freitas FG, de Souza JT, Cortés MI (2012) A multiobjective optimization approach to the software release planning with undefined number of releases and interdependent requirements. In Enterprise Information Systems (pp 300–314). Springer Berlin Heidelberg

  • Buchmann F, Nord RL, Ozakaya I (2012) Architectural Tactics to support rapid and agile stability. Carnegie-Mellon Univ Pittsburgh PA Software Engineering Inst

  • Cao L, Ramesh B, Abdel-Hamid T (2010) Modeling dynamics in agile software development. ACM Trans Manag Inf Syst (TMIS) 1(1):5

    Google Scholar 

  • Chen J, Xiao J, Wang Q, Osterweil LJ, Li M (2014, May). Refactoring planning and practice in agile software development: an empirical study. In Proceedings of the 2014 International Conference on Software and System Process (pp 55–64). ACM. (Best paper award)

  • Chen L, Babar MA (2014) “Towards an Evidence-Based Understanding of Emergence of Architecture through Continuous Refactoring in Agile Software Development.” Software Architecture (WICSA), 2014 IEEE/IFIP Conference on. IEEE

  • Dig D, Johnson R (2005, September). The role of refactorings in API evolution. In Software Maintenance, 2005. ICSM‘05. Proceedings of the 21st IEEE International Conference on (pp 389–398). IEEE

  • Dong X, Yang QS, Wang Q, Zhai J, Ruhe G (2011, December). Value-Risk Trade-off Analysis for Iteration Planning in eXtreme Programming. In Software Engineering Conference (APSEC), 2011 18th Asia Pacific (pp 397–404). IEEE

  • Drury M, Conboy K, Power K (2012) Obstacles to decision making in agile software development teams. J Syst Softw 85(6):1239–1254

    Article  Google Scholar 

  • Dybå T, Dingsøyr T (2008) Empirical studies of agile software development: a systematic review. Inf Softw Technol 50(9):833–859

    Article  Google Scholar 

  • Elssamadisy A, Schalliol G (2002, May). Recognizing and responding to bad smells in extreme programming. In Proceedings of the 24th International conference on Software Engineering (pp 617–622). ACM

  • Fink A (Ed) (2003) The survey handbook (Vol. 1). Sage

  • Fowler M (1999) Refactoring: improving the design of existing code. Pearson Education India

  • Harman M, Tratt L (2007, July) Pareto optimal search based refactoring at the design level. In Proceedings of the 9th annual conference on Genetic and evolutionary computation (pp 1106–1113). ACM

  • Jones JA, Harrold MJ, Stasko J (2002, May) Visualization of test information to assist fault localization. In Proceedings of the 24th international conference on Software engineering (pp 467–477). ACM

  • Kataoka Y, Imai T, Andou H, Fukaya T (2002) A quantitative evaluation of maintainability enhancement by refactoring. In Software Maintenance, 2002. Proceedings. International Conference on (pp 576–585). IEEE

  • Kim M, Zimmermann T, Nagappan N (2012, November) A field study of refactoring challenges and benefits. In Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering(p. 50). ACM

  • Kolb R, Muthig D, Patzke T, Yamauchi K (2006) Refactoring a legacy component for reuse in a software product line: a case study. J Softw Maint Evol Res Pract 18(2):109–132

    Article  Google Scholar 

  • Leitch R, Stroulia E (2003, May) Understanding the economics of refactoring. In EDSER-5 5 th International Workshop on Economic-Driven Software Engineering Research (p. 44)

  • Marinescu R (2005, September) Measurement and quality in object-oriented design. In Software Maintenance, 2005. ICSM‘05. Proceedings of the 21st IEEE International Conference on (pp 701–704). IEEE

  • Moser R, Abrahamsson P, Pedrycz W, Sillitti A, Succi G (2008) A case study on the impact of refactoring on quality and productivity in an agile team. In Balancing Agility and Formalism in Software Engineering (pp 252–266). Springer Berlin Heidelberg

  • Moser R, Sillitti A, Abrahamsson P, Succi G (2006) Does refactoring improve reusability?. In Reuse of Off-the-Shelf Components (pp 287–297). Springer Berlin Heidelberg

  • Murphy-Hill E, Parnin C, Black AP (2012) How we refactor, and how we know it. Softw Eng IEEE Trans 38(1):5–18

    Article  Google Scholar 

  • Negara S, Chen N, Vakilian M, Johnson RE, Dig D (2012) Using Continuous Code Change Analysis to Understand the Practice of Refactoring

  • Nidhra S, Dondeti J, Katikar P, Tekkali S (2012, September) Implementing the concept of refactoring in software development. InSoftware Engineering (CONSEG), 2012 CSI Sixth International Conference on (pp 1–8). IEEE

  • Przepiora M, Karimpour R, Ruhe G (2012, September) A hybrid release planning method and its empirical justification. In Proceedings of the ACM-IEEE international symposium on Empirical software engineering and measurement (pp 115–118). ACM

  • Rachatasumrit N, Kim M (2012, September) An empirical investigation into the impact of refactoring on regression testing. In Software Maintenance (ICSM), 2012 28th IEEE International Conference on (pp 357–366). IEEE

  • Ratzinger J, Sigmund T, Gall HC (2008, May) On the relation of refactorings and software defect prediction. In Proceedings of the 2008 international working conference on Mining software repositories (pp 35–38). ACM

  • Reddy KR, Rao AA (2009) Dependency oriented complexity metrics to detect rippling related design defects. ACM SIGSOFT Softw Eng Notes 34(4):1–7

    Article  Google Scholar 

  • Sahraoui HA, Godin R, Miceli T (2000) Can metrics help to bridge the gap between the improvement of oo design quality and its automation?. In Software Maintenance, 2000. Proceedings. International Conference on (pp 154–162). IEEE

  • Schwaber K, Beedle M (2002) Agile Software Development with Scrum

  • Schwaber K, Sutherland J (2011). Scrum guidebook. Scrum. org and Scrum Inc

  • Simon F, Steinbruckner F, Lewerentz C (2001). Metrics based refactoring. In Software Maintenance and Reengineering, 2001. Fifth European Conference on (pp 30–38). IEEE

  • Soares G, Gheyi R, Serey D, Massoni T (2010) Making program refactoring safer. Software IEEE 27(4):52–57

    Article  Google Scholar 

  • Venables WN, Smith DM, R Development Core Team (2002) An introduction to R

  • Xing Z, Stroulia E (2005, November) UMLDiff: an algorithm for object-oriented design differencing. In Proceedings of the 20th IEEE/ACM international Conference on Automated software engineering (pp 54–65). ACM

  • Yamashita A, Moonen L (2013, October) Do developers care about code smells? An exploratory survey. In Reverse Engineering (WCRE), 2013 20th Working Conference on (pp 242–251). IEEE

  • Zhang L, Kim M, Khurshid S (2011, September) Localizing failure-inducing program edits based on spectrum information. In Software Maintenance (ICSM), 2011 27th IEEE International Conference on (pp 23–32). IEEE

Download references

Acknowledgments

This research was supported by the Natural Science Foundation of China under grant Nos. 91318301, 91218302, 61432001. This work was also supported by the US National Science Foundation under Awards No. CCR-0205575, CCR-0427071, and IIS-0705772.

Author information

Authors and Affiliations

  1. Laboratory for Internet Software Technologies, Institute of Software, Chinese Academy of Sciences, Beijing, China

    Jie Chen, Junchao Xiao, Qing Wang & Mingshu Li

  2. University of Chinese Academy of Sciences, Beijing, China

    Jie Chen

  3. State Key Laboratory of Computer Science, Institute of Software, Chinese Academy of Sciences, Beijing, China

    Junchao Xiao, Qing Wang & Mingshu Li

  4. Department of Computer Science, University of Massachusetts, Amherst, MA, USA

    Leon J. Osterweil

Authors
  1. Jie Chen
    View author publications

    You can also search for this author in PubMed Google Scholar

  2. Junchao Xiao
    View author publications

    You can also search for this author in PubMed Google Scholar

  3. Qing Wang
    View author publications

    You can also search for this author in PubMed Google Scholar

  4. Leon J. Osterweil
    View author publications

    You can also search for this author in PubMed Google Scholar

  5. Mingshu Li
    View author publications

    You can also search for this author in PubMed Google Scholar

Corresponding author

Correspondence to Jie Chen.

Additional information

Communicated by: Arie van Deursen

APPENDIX-Questionnaire

APPENDIX-Questionnaire

1.1 Part A. Background Information

(Options in this part refer Table 1 in section 4.1.)

  1. 1.

    Over how many years have you been involved in Software Engineering?

  2. 2.

    How many employees in your organization?

  3. 3.

    How many years of experience do you have working in Agile methodologies?

  4. 4.

    What is your roles in the team? (Multiple choice)

  5. 5.

    Where is the team located?

  6. 6.

    What is the iteration length in the team?

  7. 7.

    How many employees in the team?

  8. 8.

    Who is the product owner?

1.2 Part B. Planning Practice

  1. 9.

    What proportion of workload does a development engineer spend for each kind of task?

    (<1 %, 1–10 %, 11–30 %,31–50 %,>50 %)

    1. A.

      Implementing new features

    2. B.

      Bug fixing

    3. C.

      Floss Refactoring

    4. D.

      Root-canal Refactoring

  2. 10.

    How do the following roles take part in the iteration planning? (Min number: 0-Max number: 5, I don’t know)

    1. A.

      Project Manager

    2. B.

      Product Manager

    3. C.

      Development Engineer

    4. D.

      Test Engineer

  3. 11.

    What is the priority of the four kinds of tasks when making an iteration plan? (Min number: 0-Max number: 5, I don’t know)

  4. 12.

    How does the team plan for the four kinds of tasks of new features?

    1. A.

      Do not make a plan to accomplish a task, but leave a needed task to be done when someone has spare time;

    2. B.

      Do not make a plan to accomplish a task, but leave some slack time to allow for the task to be done;

    3. C.

      Plan that a needed task will be done as part of another task;

    4. D.

      Make a simple plan for the critical tasks;

    5. E.

      Make a specific detailed plan for all tasks.

    6. F.

      I don’t know,

    7. G.

      Others.

1.3 Part C. Refactoring Practice

Please indicate your level of agreement of the following statements based on your experience of agile software development practices in your team. (Strongly Disagree, Disagree, Neither Agree nor Disagree, Agree, Strong Agree)

  1. 13.

    In the project, requirements change frequently and the product always deviates from its original design.

  2. 14.

    In the project, the team has enough time to do code/design reviews to ensure the code quality.

  3. 15.

    When development engineers create new features, they consider the extendibility and maintainability for most possible future changes.

  4. 16.

    In the project, the development engineers usually identify the necessity of floss refactoring before it must be done (the product has poor performance/blocks new changes).

  5. 17.

    In the project, the deferred floss refactoring will largely reduce the productivity in adding new features in the related components.

  6. 18.

    In the project, the deferred floss refactoring will largely increase the workload of adding new features in the related components.

  7. 19.

    In the project, the deferred floss refactoring will largely increase the defect density of adding new features in the related components.

  8. 20.

    In the project, the deferred floss refactoring will require a lot of extra effort to clean up the code later.

  9. 21.

    In the project, root-canal refactoring can be avoided by frequent floss refactoring.

  10. 22.

    In the project, once the need for refactoring is identified, the refactoring will subsequently be planned (or clearly plan to combine it with some new feature implement) for in a timely fashion.

    1. A.

      Low-level

    2. B.

      Medium-level

    3. C.

      High-level

  11. 23.

    In the project, once refactoring has been planned, it will actually be executed in a timely fashion.

    1. A.

      Low-level

    2. B.

      Medium-level

    3. C.

      High-level

  12. 24.

    Now, the project still have high quality of code structure suitable for supporting extendibility and maintainability.

1.4 Part D. Personal Opinion

  1. 25.

    In real project, why team doesn’t put the floss refactoring into the plan in time?

  2. 26.

    What is your ideal priority of the following tasks for the programmer? (Min number: 0-Max number: 5, I don’t care)

  3. 27.

    Any suggestion?

Rights and permissions

Reprints and permissions

About this article

Check for updates. Verify currency and authenticity via CrossMark

Cite this article

Chen, J., Xiao, J., Wang, Q. et al. Perspectives on refactoring planning and practice: an empirical study. Empir Software Eng 21, 1397–1436 (2016). https://doi.org/10.1007/s10664-015-9390-8

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10664-015-9390-8

Keywords

Search

Navigation