I have worked with development teams who never wanted to touch there code, NEVER EVER CHANGE this were some of the comments I have seen in the VSS and CVS systems that I worked with... I have seen people being over protective about their code, not wanting anyone to introduce anything. I have seen people wanting to shut down everything and write it from scratch. But none of this is really of help... it makes sense when you do one thing and over a period of time improvise it... Is it not what we call EXPERIENCE ?
Well eventually in one of the technical interviews I jammed one Sr. Engineer with a question "How much experience does the code you have written has?".. The question was not understood and neither was there any attempt to understand it... Anyways, when we say how much of experience your code has tells that you are closer to it and on it every now and then and have bought your code from all possible roll-a-coasters in the time span it is LIVE. The amount of refactoring would determine the actual experience of your code.
Over the years the Team we have worked with always showed sense in this part I think it flows because the Technical leadership has always introduced this to the new generation that took over the code. I am glad that the Team always bring this part and wants to spend time on refactoring, not always but many times...
Refactoring has always being considered AS Re-Work by any non-involved agile technician... if you are a Project Manager you understand this well... specially when you are new to this and when a developer comes to you next day he wrote the code that he wants to refactor.....
I am glad that the Team is moving towards the CODE-TEST-REFACTOR approach.. though we are running behind on the Unit testing for the UI Framework for the time being.. I think we are getting closer to a safer development approach. I am sure at the end of the release we would have some good amount of TEST , CODE and Refactored code ;)
I believe refactoring is good.. the time period is important.. I have seen refactoring working well when done in parts starting the next release at times same release. The earlier part the quality weeks were best parts of the release for refactoring.. eventually when the discipline broke developers started abusing the Quality weeks.
What benefit does refactoring bring?
1. Build a House and Stay in it the next day
If you move into a brand new house, you see no issues the next day you move in... let it run for a while and see some rains and you know what you missed. Code is similar.. you see problems when it is LIVE or even in QA, and believe me they are not BUGS.
2. Run your 10 Year old car in a F1
Can you? How can your code run then? You need to revisit it.. not only to make it faster but at times to make it smoother. Cover potential bugs, performances etc.
3. Can you have more kids with same salary as you had in 1901?
Law of scalability. Improvise and scale.
Over and Over... We are Happy that we are shaping well.