Given a small project that aims to add new functionality to application, the changes introduced touch some existing code, involving updating these in certain areas. During implementation, I've found some of these code which were updated have candidates for refactoring.
Is this an appropriate time to refactor which in turn would require regression testing for those components affected (thus possibly introducing scope not originally part of the project)? Or should I defer, complete the functionality and perhaps have a separate project for refactoring (although I'm a bit hesitant as business users might not fully sponsor a project that does not add any functionality, unless they value code maintainability…)?
Best Answer
Absolutely.
Refactoring should be done on a working and "passing" project. When all your tests (at the unit, system, and acceptance levels) pass, you know that your product meets requirements. When you refactor, you can continue to confirm that all tests continue to pass. If any test begins to fail, then you did something wrong and need to correct it. If you have failing tests, you should correct those before refactoring so you can always ensure your refactoring isn't changing the functionality of the system.
This is also a perfect time for refactoring, assuming you have the time and resources to carry out the refactoring and still deliver on time and budget. Refactoring now will make it easier to understand and maintain your system, so as you add even more new features, it becomes easier. You need to fight against code rot and software entropy.
As Joel Etherton points out in the comments, you need to manage the scope of refactoring. Focus on refactoring the parts of the system that you will soon be adding features to, performing refactorings that will make it easier to work with or add the new features. The use of static analysis, metrics tools, and code reviews can help you identify areas that are most critical. You don't want to miss deadlines because you were refactoring - you still need to continue to add value to the customer.
You mention the customer not seeing value in refactoring. Typically, the customer doesn't care about the quality of the code, but of the product. Refactoring will make it easier for you to maintain a high product quality and keep delivering a product that meets the changing needs of the customer. Try to negotiate time to refactoring into your schedule (customer wants X features in Y days, try to see if you can't get Y+Z days or X-N features so you can spend time on design, refactoring, and implementation), if you can.