Refactoring and ROI
Is refactoring code worth the effort? I know many project managers equate refactor with rework. They not even ready to hear this word. I will share one of my refactoring experience:
I was working on a fixed price project. We were following some agile practices. But managers were not in favour of following complete agile. In their words you do whatever you want as long as it follows what I want. Still we had SCRUM meetings, SCRUM board, test driven development. Again no SPRINT planning. SPRINT was derived from the project plan and product owner was the business analyst.
There were two pages which had price calculation. Over time lot of functionality was added to these two pages and they had started acting cranky. As usual commander had called a meeting and started to blast everyone in the visinity. During this process I uttered the word we will refactor the page. All the hell broke loose. Top manager (commander) and his deputy started to look at me like a intruder. Then after some time they overcame thier initial shock and started with questions.
Why do you need to spend extra effort? Do you know refactoring can introduce more bugs? How will we afford the testing effort? Entire application has to be tested if this is done. Why despite so many code reviews this page is cranking and how will a refactor help it? If some funtionality is removed in refactoring how to identify it?
There were many more. Some of them I have blocked in memory. Now the next part. Since I did the mistake of uttering the word I answered:
Anyway this page is not behaving as it should. We will need to add more functionality in the future and this page will not support it. So let me work on this. If things become worse you can always go back to earlier version. I will work on this a weekend and give you a better functionality.
And I came on a weekend. Took a notepad. Listed the functionality of the page. What are the triggers and what are expected output. Wrote tests for the same. Extracted new methods and aloha in 6 hours a hotrod page is born. It did all the functionality which was expected out of the page. Design was better. Methods were doing what thier names suggested. Code was readable. And page was leaner. Earlier page had 300 lines of code. Now the page had around 120 lines.
Now coming to ROI part. I had only spent 6 hours. This saved more than 20 hours in issue fixing. I am not able to measure the savings in impact analysis for future development. But it will be significant.
From that day I was able to convince the non believers to agree to refactor. In Martin Fowlers words refactoring is Improving the design of existing code. This is very important as design (in SDLC terms) is obsolete even before design document is reviewed. Typically a senior does the desing and hands it over to the developer. Developer codes the design. During unit testing developer fixes issues and some how makes the functionality work. But if you validate the functionality against design I will bet more than 70% of the functionality is not following the design.
I am not complaining about this. But refactoring the code is a good option. You can follow the third time rule. First time you are developing something - no refactoring, things are working.
Second time you need to touch the page - evaluate is it nescessary.
Third time you need to touch the page - Don't look anywhere. Just go ahead and refactor the page.
ROI will come by the way of better maintainability. Also will come by the way of lesser number of issues. It is always easy to refactor than to do a perfect design in first place. Your knowledge of requirement by the piece of code is lot better than when some one designed it in the beginning.
I was working on a fixed price project. We were following some agile practices. But managers were not in favour of following complete agile. In their words you do whatever you want as long as it follows what I want. Still we had SCRUM meetings, SCRUM board, test driven development. Again no SPRINT planning. SPRINT was derived from the project plan and product owner was the business analyst.
There were two pages which had price calculation. Over time lot of functionality was added to these two pages and they had started acting cranky. As usual commander had called a meeting and started to blast everyone in the visinity. During this process I uttered the word we will refactor the page. All the hell broke loose. Top manager (commander) and his deputy started to look at me like a intruder. Then after some time they overcame thier initial shock and started with questions.
Why do you need to spend extra effort? Do you know refactoring can introduce more bugs? How will we afford the testing effort? Entire application has to be tested if this is done. Why despite so many code reviews this page is cranking and how will a refactor help it? If some funtionality is removed in refactoring how to identify it?
There were many more. Some of them I have blocked in memory. Now the next part. Since I did the mistake of uttering the word I answered:
Anyway this page is not behaving as it should. We will need to add more functionality in the future and this page will not support it. So let me work on this. If things become worse you can always go back to earlier version. I will work on this a weekend and give you a better functionality.
And I came on a weekend. Took a notepad. Listed the functionality of the page. What are the triggers and what are expected output. Wrote tests for the same. Extracted new methods and aloha in 6 hours a hotrod page is born. It did all the functionality which was expected out of the page. Design was better. Methods were doing what thier names suggested. Code was readable. And page was leaner. Earlier page had 300 lines of code. Now the page had around 120 lines.
Now coming to ROI part. I had only spent 6 hours. This saved more than 20 hours in issue fixing. I am not able to measure the savings in impact analysis for future development. But it will be significant.
From that day I was able to convince the non believers to agree to refactor. In Martin Fowlers words refactoring is Improving the design of existing code. This is very important as design (in SDLC terms) is obsolete even before design document is reviewed. Typically a senior does the desing and hands it over to the developer. Developer codes the design. During unit testing developer fixes issues and some how makes the functionality work. But if you validate the functionality against design I will bet more than 70% of the functionality is not following the design.
I am not complaining about this. But refactoring the code is a good option. You can follow the third time rule. First time you are developing something - no refactoring, things are working.
Second time you need to touch the page - evaluate is it nescessary.
Third time you need to touch the page - Don't look anywhere. Just go ahead and refactor the page.
ROI will come by the way of better maintainability. Also will come by the way of lesser number of issues. It is always easy to refactor than to do a perfect design in first place. Your knowledge of requirement by the piece of code is lot better than when some one designed it in the beginning.
The fact that you had to do this on weekend is the issue we should all address.
ReplyDelete